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.