Kravhantering

Funktionella och icke funktionella krav

Funktionella req

Processen för att bestämma de service som ett system skall ge och de restriktioner som finns och skall utvecklas.

Vad är ett krav? (requirement)

descriptions of what the system should do. the services that it provides and the constraints on its operation. the need of customers for a system.

Requirements engineering

The process of finding out, analyzing, documenting and checking these services and constraints.

Viktigt att skilja på ett abstrakt dokumentation om req och ett dokument om detaljer kring klienten så kunden kan validera systemet.

User reqruirements

System requirements.

high-level abstract statement

Of services of a system

or constraints

Dual function:

may be basis for a bid for a contract, must be open to interpretation

may be the basis for the contract itself- therefore must be defined in detail.

User requirements

System requirements

se s 101 för bild på skillnad (bok) s7 pp.

Natural language, what service system rpovides and its operational constraints. basic written for customers

strukturerat dokument med detaljerad beskrivning av system funktionerna, service, funktionella restriktioner. between client and contractor. Som ett kontrakt.

Läsare som, client managers, system end-users, client engineers, cranctor managers, system achitectrs.

Läsare som, system endusers, client (beställare/kund) engineers, system architect, sw developers.

System stakeholders (intressenter)

Slutanvändare

system förvaltare

system ägare

externa intressenter

Exempel se s.9 pp

Agile metoder och krav

Many agile methods argue that producing detailed
system requirements is a waste of time as requirements change so quickly.

becomes out of date (req-document)

Agile methods usually use incremental requirements
engineering and may express requirements as ‘user
stories’
( litet kort med bestående av who, what and why.) kort och koncist

User stories funkar ej för kritiska system som kräver föranalyser och utecklas av flera team. endast bizznizz system (enkla)

Icke-funktionella req

beskrivning av tjänster som systemet ska ge och hur systemet ska reagera till olika input och hur de ska reagera i olika situationer.

Även vad systemet inte skall utföra

restriktioner av tjänster och funktioner gällande systemet , såsom timing, utvecklings processen och standard osv.

beskrivs abstrakt för user req. men i detalj till system req

Funktionella req måste beskriva tjäsnterna i detalj då de enkelt kan bli missförstånd.

När de ej är det kan bli missförstånd mellan användare och utvecklare

"sök" exempel i pp s17

Consistent and complete, men för att det är så komplext kan man nästan inte skapa ett helt komplett req document

System properties, eg reliability, respose time and storage reqiurements.

Stakeholders have different—
and often inconsistent—needs.

Non-functional requirements, such as performance, security, or availability, usually
specify or constrain characteristics of the system as a whole.

Non-functional requirements
are often more critical than individual functional requirements.

System users can
usually find ways to work around a system function that doesn’t really meet their needs.
However, failing to meet a non-functional requirement can mean that the whole system
is unusable.

For example, if an aircraft system does not meet its reliability requirements,
it will not be certified as safe for operation; if an embedded control system fails to meet
its performance requirements, the control functions will not operate correctly.

A single non-functional requirement, such as a security requirement, may generate
a number of related functional requirements that define new system services that
are required.

Icke-funktionella krav kan komma ifrån se s105 bok. se pp model s 23

Produkt req

Organisationell req

external req

Requirements which specify that the delivered product must
behave in a particular way e.g. execution speed, reliability, etc.

Requirements which are a consequence of organisational
policies and procedures e.g. process standards used,
implementation requirements, etc.

Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.

Mål och req

Icke-funketionella req kan svara svåra att beskriva

Därför används mål, som är en generell avsikt av anvädnaren, såsom ease of use

Mål (goals) är bra för utvecklare för att de förmedlar system användarnas avsikter.

Har som mål att försöka utveckla utifrån användarnas avsikt med req. i princip.

OLIKA Icke - funktionella (nonfucntional) requirement

Hastighet (speed)

Storlek

Ease of use

tränings tid och hjälp som användarna får för att kunna använda systemet

tillförlitlighet (reliability)

Robusthet

Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure

Portability (flyttbarhet)

svårt att överföra mål till mätbara krav.

Processes

Olika beroende på application domain, människor involverade och organisations utvecklings req

General activities that are interleaved

Analysis

Requirements Validation

Elicitation, discovery

Management, förvalta req förändringar nya som gamla system.

SW engineers work with customers and end users to find out about what services the system should provide, req performance, HW osv.

May involve end-users, managers, engineers involved in
maintenance, domain experts, trade unions, etc. These
are called stakeholders.

Steg som ingår requirement-

classification and organization

prioritization and negotition

Discovery

Requirements Specification

grouping requirements is
to use a model of the system architecture to identify sub-systems and to associate
requirements with each sub-system.

interacting with stakeholders of the
system to discover their requirements. And gather information through interview

when multiple stakeholders
are involved, requirements will conflict. Prioritizing requirements and finding and resolving requirements conflicts through negotiation. Usually, stakeholders have to meet to resolve differences and agree on compromise requirements.

Formellt eller informellt

Iterativ

Problem:

Intressenter vet inte alltid vad de vill ha

express requirements in their own terms.

Different stakeholders may have conflicting
requirements.

Organisational and political factors may influence the
system requirements. icke funktionella

The requirements change during the analysis process.
New stakeholders may emerge and the business
environment may change

Formal or informal interviews. (closed and open interviews, predetermined questions or various exploration.

In order to be effektiv,

Prompt the interviewee to get discussions going using a
springboard question, a requirements proposal, or by working
together on a prototype system.

be open.minded, avoid pre conceived ideas about the req, and listen!

SvårigheterLink Title

They normally use terminology in a precise and subtle way that is easy for requirements engineers to misunderstand. Eftersom de är inte specialister i samma arbetsområden. det är där vi kommer in

Some domain knowledge is so familiar to stakeholders that they either find it difficult to explain or they think it is so fundamental that it isn’t worth mentioning.
For example, for a librarian, it goes without saying that all acquisitions are catalogued before they are added to the library. However, this may not be obvious to the interviewer, and so it isn’t taken into account in the requirements.

Interviews are also not an effective technique for eliciting knowledge about organizational
requirements and constraints because there are subtle power relationships
between the different people in the organization.

Ethnography

A social scientist spends a considerable time observing
and analysing how people actually work.

People do not have to explain or articulate their work. svårighet att beskriva också

Social and organisational factors of importance may be
observed.

Ethnographic studies have shown that work is usually
richer and more complex than suggested by simple
system models.

Hur man tillämpar Ethnography på krav inhämtning

Requirements that are derived from the way that people
actually work rather than the way I which process
definitions suggest that they ought to work.

Krav som härstammar från samarbeten och kännedom om människors aktiviteter

Kännedom om vad andra människor gör leder till förändringar i sättet som vi gör saker

OBS!

Ethnography is effective for understanding existing
processes but cannot identify new features that should
be added to a system.

Komplement till krav insamling

Bra att kombineras med prototyp.

Problem:

The problem with ethnography is that it studies existing
practices which may have some historical basis which is
no longer relevant.

Scenarios, real-life examples rather than abstract descpriptions for a particular task

User stories är en req scenario

Because they are based on a practical situation,
stakeholders can relate to them and can comment on
their situation with respect to the story.

Strukturerad form av användar story bör innehålla:

A description of the starting situation;

A description of what can go wrong;

Information about other concurrent activities;

A description of the state when the scenario finishes.

A description of the normal flow of events;

Use cases

a kind of scenario

identify the actors in an interaction and which
describe the interaction itself. namnge interaktionen.

A set of use cases should describe all possible
interactions with the system

Actors in the process, who may be human or other systems, are represented
as stick figures.

Use cases identify the individual interactions between the system and its users or
other systems. Each use case should be documented with a textual description.

Scenarios and use cases are effective techniques for eliciting requirements from stakeholders who interact directly with the system. Each type of interaction can be represented as a use case.

The process of writing down the user and system
requirements in a requirements document.

User requirements have to be understandable by endusers and customers who do not have a technical
background.

System requirements are more detailed requirements
and may include more technical information.

The requirements may be part of a contract for the
system development

It is therefore important that these are as complete as possible.

Olika sätt att skriva system requirements

Natural language

Design description
languages

Structured natural
language

Graphical notations

M a t h e m a t i c a l
specifications. svår för köpare att förstå

The requirements are written using numbered sentences in natural language. Each sentence should express one requirement.

The requirements are written in natural language on a standard form or template. Each field provides information about an aspect of the requirement.

These notations are based on mathematical concepts such as finite-state
machines or sets

Graphical models, supplemented by text annotations, are used to define the
functional requirements for the system; UML use case and sequence
diagrams are commonly used.

In principle, requirements should state what the system should do and the design should describe how it does this. Går ej att separera

A system architecture may be designed to structure the
requirements;

The system may inter-operate with other systems that generate
design requirements;

The use of a specific architecture to satisfy non-functional
requirements may be a domain requirement.

This may be the consequence of a regulatory requirement.

Used for writing requirements because it is expressive,
intuitive and universal. This means that the requirements
can be understood by users and customers.

Hur man skriver krav

ha ett standard format och använd det till alla krav

Use language in a consistent way. Use shall for
mandatory requirements, should for desirable
requirements

Use text highlighting to identify key parts of the
requirement.

Avoid the use of computer jargon.

Computer jargon means words to do with computers and surrounding topics. Knowing what these words mean can help people know more about computers.

Include an explanation (rationale) of why a requirement
is necessary.

Problem med natural språk

Precision is difficult without making the document difficult to read. Lack of clarity

Requirements confusion Functional and non-functional requirements tend to be mixed-up.

Requirements amalgamation Several different requirements may be expressed together.

show how a state changes or
when you need to describe a sequence of actions.

Form based specifications

Information about the information needed for the
computation and other entities used.

Information about the information needed for the
computation and other entities used.

Description of outputs and where they go to.

Description of the action to be taken.

Description of inputs and where they come from

Pre and post conditions (if appropriate).

Definition of the function or entity.

The side effects (if any) of the function.

SW requirement document

The software requirements document is the official
statement of what is required of the system developers.

Should include both a definition of user requirements and
a specification of the system requirements.

It is NOT a design document. As far as possible, it
should set of WHAT the system should do rather than
HOW it should do it.

Vem och vad används documentet till pp s66

Requirements document variability.

Information in requirements document depends on type of system and the approach to development used.

Systems developed incrementally will, typically, have less detail in the requirements document.

Requirements documents standards have been
designed e.g. IEEE standard. These are mostly
applicable to the requirements for large systems
engineering projects.

Strukturen i ett krav dokument

Glossory

User requirements definition

Introduction

System Architecture

Preface

This should define the expected readership of the document and describe its version history, including a rationale for the creation of a new version and a summary of the changes made in each version.

This should describe the need for the system. It should briefly describe the system’s functions and explain how it will work with other systems. It should also describe how the system fits into the overall business or strategic objectives of the organization commissioning the software.

This should define the technical terms used in the document. You should not make assumptions about the experience or expertise of the reader.

you describe the services provided for the user. The nonfunctional system requirements should also be described in this section. This description may use natural language, diagrams, or other notations that
are understandable to customers. Product and process standards that must be followed should be specified.

present a high-level overview of the anticipated
system architecture, showing the distribution of functions across system modules. Architectural components that are reused should be highlighted

System requirements

This should describe the functional and nonfunctional requirements in more detail. If necessary, further detail may also be added to the nonfunctional requirements.
Interfaces to other systems may be defined.

System models

This might include graphical system models showing the relationships between the system components and the system and its environment.

System evolution

This should describe the fundamental assumptions on which the system is based,and any anticipated changes due to hardware evolution, changing user needs,
and so on. This section is useful for system designers as it may help them avoid design decisions that would constrain likely future changes to the system.

Appendices

These should provide detailed, specific information that is related to the application being developed; for example, hardware and database descriptions.
Hardware requirements define the minimal and optimal configurations for the system. Database requirements define the logical organization of the data used
by the system and the relationships between data.

Index

Several indexes to the document may be included. As well as a normal alphabetic index, there may be an index of diagrams, an index of functions, and so on. (register)

Concerned with demonstrating that the requirements
define the system that the customer really wants.

Requirements error costs are high so validation is very
important

Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.

Requirements checking

Validity. Does the system provide the functions which
best support the customer’s needs?

Consistency. Are there any requirements conflicts?

Completeness. Are all functions required by the
customer included?

Realism. Can the requirements be implemented given
available budget and technology

Verifiability. Can the requirements be checked?

Requirements validation techniques

Requirements reviews

Prototyping

Test-case generation

tester som kollar om de uppfyller kraven

Systematic manual analysis of the requirements.

Using an executable model of the system to check requirements. experimentera

Ultimately, it is difficult to show that a set of requirements does in fact meet a user’s needs. Users need to picture the system in operation and imagine how that system
would fit into their work. It is hard even for skilled computer professionals to perform this type of abstract analysis and harder still for system users. As a result, you rarely find all requirements problems during the requirements validation process.