Tvorba informačných systémov 2. prednáška čo všetko sa týka špecifikácie požiadaviek

Transcription

1 Tvorba informačných systémov 2. prednáška čo všetko sa týka špecifikácie požiadaviek

2 Informačný systém (softvér) Dve kategórie IS: krabicový softvér predáva sa na trhu všeobecnej verejnosti (generické produkty), napr. Office, operačné systémy, počítačové hry,... softvér na mieru vytvorený pre konkrétne špecifické potreby zákazníka (produkty na zakázku), napr. zdravotná alebo sociálna poisťovňa, správa smetiarskych vozidiel, V prvom prípade si požiadavky stanovuje samotná softvérová firma, v druhom prípade je potrebné vyhovieť konkrétnym potrebám zákazníka, tvorcovia IS majú omnoho menej slobody.

3 Zabezpečenie a určenie kvality softvéru Model kvality (ISO/IEC ) Externé atribúty kvality z hľadiska behu softvéru Interné atribúty kvality vlastnosti z hľadiska vývojára Atribúty kvality použitia vlastnosti hotového produktu

4 Zabezpečenie a určenie kvality softvéru Externé atribúty kvality: spoľahlivosť: softvér pracuje podľa špecifikácie (správnosť) + správa sa rozumne aj v prípadoch nepokrytých špecifikáciou (robustnosť) flexibilnosť: jednoduchosť zmeny softvéru v prípade zmien požiadaviek/prostredia znovupoužiteľnosť: možnosť použiť softvér (jeho časti) v iných kontextoch kompatibilnosť (interoperabilita): možnosť použiť SW produkt s inými produktami

5 efektívnosť: schopnosť minimalizovať požiadavky na HW (CPU, interná/externá pamäť, komunikačné kanály,...) portabilita: jednoduchosť prenesenia softvéru na inú HW/SW platformu jednoduchosť použitia: miera námahy potrebnej na zaškolenie a používanie softvéru; vrátane jeho inštalácie a správy ISO/IEC 9126 Software engineering Product quality ISO/IEC 25000: Software engineering: Software product Quality Requirements and Evaluation (SquaRE) môžu byť uvedené ako non-functional requirements (požiadavky, ktoré nepopisujú funkcionalitu) Nie je možné dosiahnuť všetky naraz!

6 Interné atribúty kvality: (neviditeľné pre vonkajšieho pozorovateľa, avšak podstatné pre dosahovanie externých atribútov), napr. modulárnosť (vhodná architektúra) zrozumiteľnosť kódu minimum rozhraní minimálne rozhrania

7 Proces vývoja softvéru množina aktivít, ktorej výsledkom je softvérový produkt 4 hlavné druhy technických aktivít sú: špecifikácia SW produktu vývoj (návrh + implementácia) SW produktu validácia SW produktu evolúcia SW produktu

8 ISO/IEC ISO/IEC 15288

9 Štruktúra nákladov na vývoj softvéru závisí od druhu produktu a od procesu vývoja pred odovzdaním: cca 60% vývoj, 40% testovanie pri generických produktoch je objem testovania väčší rovnako pri kritických systémoch evolúcia: 2-3x viac než náklady do odovzdania (platí pri produktoch na zákazku)

10 Úspešnosť SW projektov Challenged: prekročenie času/rozpočtu a/alebo nesplnenie požiadaviek Failed: výsledok projektu nebol uvedený do prevádzky Zdroj: Standish Chaos Reports

11 Úspešnosť SW projektov Succeeded 16% 27% 26% 28% 34% 29% 32% Failed 31% 40% 28% 23% 15% 18% 24% Challenged 53% 33% 46% 49% 51% 53% 44% National Institute of Standards and Technology (NIST) * Software defects cost nearly $60 Billion Annually * 80% of development costs involve identifying and correcting defects More:

12 Hlavné role v procese vývoja SW zadávateľ (zákazník, klient) riešiteľ (dodávateľ, vývojár, developer) používateľ (end-user) a ďalšie, napr. prevádzkovateľ stakeholder

13 Špecifikácia požiadaviek cieľ: vytvorenie uceleného katalógu požiadaviek na produkt (t.j. čo zadávateľ od produktu požaduje) výsledok (špecifikácia požiadaviek) obsahuje: popis funkcií produktu popis údajov, s ktorými produkt pracuje ostatné vlastnosti produktu a obmedzenia naň kladené (tzv. non-functional requirements) špecifikácia je záväzná pre zadávateľa aj riešiteľa

14 vlastnosti: špecifikácia požiadaviek musí byť zrozumiteľná pre zadávateľa aj riešiteľa musí byť jednoznačná, úplná a vnútorne konzistentná prostriedky: neformálne: prirodzený jazyk, diagramy,... semiformálne: čiastočne formalizované jazyky (napr. UML) formálne: jazyky s matematickým základom (napr. Z) čím formálnejšie prostriedky, tým je špecifikácia presnejšia, ale pre laika menej zrozumiteľná; plne formálne jazyky sa používajú len v určitých prípadoch (napr. kritické systémy) problém: zadávateľ si nevie jasne predstaviť, ako bude výsledný systém vyzerať riešiteľ nie je expert v oblasti, pre ktorú systém implementuje riešenie: čo najviac kvalitnej komunikácie!

15 Jednoznačné? 3.4.A. Z terminálu sa načíta identifikátor súčiastky nasledovaný identifikátorom kontajnera. Ak tento obsahuje písmená AQ, treba cenu prenesenia danej súčiastky do daného kontajnera násobiť koeficientom 1,5. Konzistentné? časť 4 - bezpečnostné charakteristiky 4.1. Ak tlak v pracovnej nádobe presiahne 10 atmosfér, je potrebné okamžite uzavrieť ventil M17. časť 8 - komunikácia s operátorom 8.2. Ak tlak v pracovnej nádobe presiahne stanovenú hodnotu, je potrebné upovedomiť operátora. Ak operátor nezareaguje do 30 sekúnd, treba vykonať príslušné opatrenia.

16 Kontext vytvárania katalógu požiadaviek Jadrové úlohy Tvorba katalógu požadaviek Analýza Návrh Implementácia Testovanie Podporné úlohy Riadenie projektu Správa konfigurácie a zmien Zabezpečenie kvality Zaškolenie 16

17 RE process - inputs and outputs E x i s t i n g s y s t e m s i n f o r m a t i o n S t a k e h o l d e r n e e d s A g r e e d r e q u i r e m e n t s O r g a n i s a t i o n a l s t a n d a r d s R e q u i r e m e n t s e n g i n e e r i n g p r o c e s s S y s t e m s p e c i f i c a t i o n R e g u l a t i o n s S y s t e m m o d e l s D o m a i n i n f o r m a t i o n 17

18 RE process variability RE processes vary radically from one organisation to another Factors contributing to this variability include Technical maturity Disciplinary involvement Organisational culture Application domain There is therefore no ideal requirements engineering process 18

19 Coarse-grain activity model of RE R e q u i r e m e n t s e l i c i t a t i o n R e q u i r e m e n t s a n a l y s i s a n d n e g o t i a t i o n R e q u i r e m e n t s d o c u m e n t a t i o n R e q u i r e m e n t s v a l i d a t i o n U s e r n e e d s d o m a i n i n f o r m a t i o n, e x i s t i n g s y s t e m i n f o r m a t i o n, r e g u l a t i o n s, s t a n d a r d s, e t c. R e q u i r e m e n t s d o c u m e n t S y s t e m s p e c i f i c a t i o n A g r e e d r e q u i r e m e n t s 19

20 Spiral model of the RE process D e c i s i o n p o i n t : A c c e p t d o c u m e n t o r r e - e n t e r s p i r a l I n f o r m a l s t a t e m e n t o f r e q u i r e m e n t s R e q u ir e m e n t s e l ic i ta t io n R e q u i re m e n t s a n a ly s i s a n d n e g o t i a t i o n R e q u i r e m e n t s d o c u m e n t a n d v a l i d a t i o n r e p o r t S T A R T A g r e e d r e q u i r e m e n t s R e q u i r e m e n t s v a l i d a t i o n R e q u i r e m e n t s d o c u m e n t a t i o n D r a f t r e q u i r e m e n t s d o c u m e n t 20

21 Human and social factors Requirements engineering processes are dominated by human, social and organisational factors because they always involve a range of stakeholders from different backgrounds and with different individual and organisational goals. System stakeholders may come from a range of technical and non-technical background and from different disciplines 21

22 Types of stakeholder Software engineers responsible for system development System end-users who will use the system after it has been delivered Managers of system end-users who are responsible for their work External regulators who check that the system meets its legal requirements Domain experts who give essential background information about the system application domain 22

23 RE process problems Lack of stakeholder involvement Business needs not considered Lack of requirements management Lack of defined responsibilities Stakeholder communication problems Over-long schedules and poor quality requirements documents 23

24 Katalóg požiadaviek je formálnym dokumentom, ktorý ako základ komunikácie používajú zákazníci, vývojári a management opisuje Služby a funkcie, ktoré má systém poskytovať Obmedzenia (constraints) podmienok, v ktorých softvér bude pracovať Celkové vlastnosti systému, vrátane obmedzení na vyplývajúce vlastnosti Definície ostatných systémov s ktorými bude systém integrovaný. 24

25 Katalóg požiadaviek ďalej opisuje: Informácie z oblasti príslušnej aplikačnej domény ako v nej prebiehajú procesy, výpočty, aké sú závislosti Všetky obmedzenia na spôsob vývoja softvéru Hardvér i softvér na ktorom sa má systém prevádzkovať V každom prípade by katalóg požiadaviek mal obsahovať úvodnú kapitolu s celkovým prehľadom systému, komerčnými potrebami z ktorých vychádza zákazka a slovníkom pojmov, ktorý vysvetľuje použitú terminológiu. 25

26 Users of requirements documents System customers specify the requirements and read them to check they meet their needs Project managers Use the requirements document to plan a bid for system and to plan the system development process System engineers Use the requirements to understand the system being developed System test engineers Use the requirements to develop validation tests for the system System maintenance engineers Use the requirements to help understand the system 26

27 Requirements categories overview Problem Needs Problem space Features Solution space Software Requirements 27

28 It It is is important to to understand that, (except where problem is is motivated by the technology), the problem is is an artifact of of the problem domain and is is generally technology neutral. 28

29 Requirements problems The requirements don t reflect the real needs of the customer for the system. Requirements are inconsistent and/or incomplete. It is expensive to make changes to requirements after they have been agreed. There are misunderstandings between customers, those developing the system requirements and software engineers developing or maintaining the system. 29

30 The requirements elicitation process E s t a b l i s h o b j e c t i v e s U n d e r s t a n d b a c k g r o u n d O r g a n i s e k n o w l e d g e C o l l e c t r e q u i r e m e n t s B u s i n e s s g o a l s O r g a n i s a t i o n a l s t r u c t u r e S t a k e h o l d e r i d e n t i f i c a t i o n S t a k e h o r e q u i r e m l d e r e n t s P r o b l e m t o b e s o l v e d A p p l i c a t i o n d o m a i n G o a l p r i o r i t i s a t i o n D o m a i n r e q u i r e m e n t s S y s t e m c o n s t r a i n t s E x i s t i n g s y s t e m s D o m a i n k n o w l e d g e f i l t e r i n g O r g a n i s a t i o n a l r e q u i r e m e n t s 30

31 Elicitation stages Objective setting The organisational objectives should be established including general goals of the business, an outline description of the problem to be solved, why the system is necessary and the constraints on the system. Background knowledge acquisition Background information about the system includes information about the organisation where the system is to be installed, the application domain of the system and information about existing systems Knowledge organisation The large amount of knowledge which has been collected in the previous stage must be organised and collated. Stakeholder requirements collection System stakeholders are consulted to discover their requirements. 31

32 Interviews The requirements engineer or analyst discusses the system with different stakeholders and builds up an understanding of their requirements. Types of interview Closed interviews. The requirements engineer looks for answers to a pre-defined set of questions Open interviews There is no predefined agenda and the requirements engineer discusses, in an open-ended way, what stakeholders want from the system. 32

33 Interviewing essentials Interviewers must be open-minded and should not approach the interview with preconceived notions about what is required Stakeholders must be given a starting point for discussion. This can be a question, a requirements proposal or an existing system Interviewers must be aware of organisational politics - many real requirements may not be discussed because of their political implications 33

34 Scenarios Scenarios are stories which explain how a system might be used. They should include a description of the system state before entering the scenario the normal flow of events in the scenario exceptions to the normal flow of events information about concurrent activities a description of the system state at the end of the scenario Scenarios are examples of interaction sessions which describe how a user interacts with a system Discovering scenarios exposes possible system interactions and reveals system facilities which may be required 34

35 Library scenario - document ordering Log on to EDDIS system Issue order document command Enter reference number of the required document Select a delivery option Log out from EDDIS This sequence of events can be illustrated in a diagram 35

36 Library Scenario U s e r i d P a s s w E x d O p e r a t i o n a l t e r m i n a l c e p t i o n s L o g i n t o E D D I S I n v a l i d i d o r p a s s w o r d L o g i n r e t r y L o g i n O S e l e c t o r d e r d o c u m e n t P e r m E n K E x c e p t i o n s i s s i o n d e n i e d t e r h e l p s y s t e m O r d e r a c c e p t e d I n p u t d o c u m e n t r e f e r e n c e E n E x I n c o r r e c t r e f e r e n c e I n p u t d o c. r e f e r e n c e D o c u m e n t r e f e r e n c e O K c e p t i o n s t e r h e l p s y s t e m D e l i v e r y c o n f i r m e d C o n f i r m d e l i v e r y d e t a i l s L o g o u t f r o m E D D I S E x c e p t i o n s T i m e o u t A u t o - l o g o u t 36

37 Scenarios and OOD Scenarios are an inherent part of some object-oriented development methods The term use-case (i.e. a specific case of system usage) is sometimes used to refer to a scenario There are different views on the relationship between use-cases and scenarios: A use-case is a scenario A scenario is a collection of use-cases. Therefore, each exceptional interaction is 37 represented as a separate use-case

38 Typical use-case scenario for library system a c c e s s s e r v i c e s < < u s e s > > u s e r p e r m i s s i o n s L i b r a r y u s e r b r o w s e i t e m < < u s e s > > s e a r c h c r i t e r i a r e g i s t e r u s e r L i b r a r y s t a f f U s e C a s e s e t p e r m i s s i o n s < < e x t e n d s > > 38

39 Event scenario for borrowing item L i b r a r y U s e r ( L U ) S y s t e m L i b r a r y s t a f f R e q u e s t s l i b r a r y i t e m ( 1 ) S c a n s i n L U r e g i s t r a t i o n ( 2 ) a c c e p t s r e g i s t r a t i o n ( 3 ) r e j e c t s r e g i s t r a t i o n ( 3 ) v e r i f i e s i t e m l o a n t o L U ( 4 ) l o a n s i t e m ( 5 ) d e n i e s l o a n ( 5 ) 39

40 Observation and social analysis People often find it hard to describe what they do because it is so natural to them. Sometimes, the best way to understand it is to observe them at work Ethnography is a technique from the social sciences which has proved to be valuable in understanding actual work processes Actual work processes often differ from formal, prescribed processes An ethnographer spends some time observing people at work and building up a picture of how work is done 40

41 Prototyping A prototype is an initial version of a system which may be used for experimentation Prototypes are valuable for requirements elicitation because users can experiment with the system and point out its strengths and weaknesses. They have something concrete to criticise Rapid development of prototypes is essential so that they are available early in the elicitation process 41

42 Prototyping benefits The prototype allows users to experiment and discover what they really need to support their work Establishes feasibility and usefulness before high development costs are incurred Essential for developing the look and feel of a user interface Can be used for system testing and the development of documentation Forces a detailed study of the requirements which reveals inconsistencies and omissions 42

43 Types of prototyping Throw-away prototyping intended to help elicit and develop the system requirements. The requirements which should be prototyped are those which cause most difficulties to customers and which are the hardest to understand. Requirements which are wellunderstood need not be implemented by the prototype. Evolutionary prototyping intended to deliver a workable system quickly to the customer. Therefore, the requirements which should be supported by the initial versions of this prototype are those which are wellunderstood and which can deliver useful end-user functionality. It is only after extensive use that poorly understood requirements should be implemented. 43

44 Prototyping costs and problems Training costs - prototype development may require the use of special purpose tools Development costs - depend on the type of prototype being developed Extended development schedules - developing a prototype may extend the schedule although the prototyping time may be recovered because rework is avoided Incompleteness - it may not be possible to prototype critical system requirements 44

45 Approaches to prototyping Paper prototyping a paper mock-up of the system is developed and used for system experiments Wizard of Oz prototyping a person simulates the responses of the system in response to some user inputs Executable prototyping a fourth generation language or other rapid development environment is used to develop an executable prototype 45

46 Requirements analysis and negotiation R e q u i r e m e n t s a n a l y s i s N e c e s s i t y c h e c k i n g C o n s i s t e n c y a n d c o m p l e t e n e s s c h e c k i n g F e a s i b i l i t y c h e c k i n g U n n e c e s s a r y r e q u i r e m e n t s C o n f l i c t i n g a n d i n c o m p l e t e r e q u i r e m e n t s I n f e a s i b l e r e q u i r e m e n t s R e q u i r e m e n t s d i s c u s s i o n R e q u i r e m e n t s p r i o r i t i s a t i o n R e q u i r e m e n t s a g r e e m e n t R e q u i r e m e n t s n e g o t i a t i o n 46

47 Requirements analysis The goal of analysis is to discover problems, incompleteness and inconsistencies in the elicited requirements. These are then fed back to the stakeholders to resolve them through the negotiation process Analysis is interleaved with elicitation as problems are discovered when the requirements are elicited A problem checklist may be used to support analysis. Each requirement may be assessed against the checklist 47

48 Analysis checklists Premature design Does the requirement include premature design or implementation information? Combined requirements Does the description of a requirement describe a single requirement or could it be broken down into several different requirements? Unnecessary requirements Is the requirement gold plating? That is, is the requirement a cosmetic addition to the system which is not really necessary. Use of non-standard hardware Does the requirement mean that non-standard hardware or software must be used? To make this decision, you need to know the computer platform requirements. 48

49 Analysis checklists Conformance with business goals Is the requirement consistent with the business goals defined in the introduction to the requirements document? Requirements ambiguity Requirements ambiguity Is the requirement ambiguous i.e. could it be read in different ways by different people? What are the possible interpretations of the requirement? Requirements realism Is the requirement realistic given the technology which will be used to implement the system? Requirements testability Is the requirement testable, that is, is it stated in such a way that test engineers can derive a test which can show if the system meets that requirement? 49

50 Requirements interactions A very important objective of requirements analysis is to discover the interactions between requirements and to highlight requirements conflicts and overlaps A requirements interaction matrix shows how requirements interact with each other. Requirements are listed along the rows and columns of the matrix For requirements which conflict, fill in a 1 For requirements which overlap, fill in a 1000 For requirements which are independent, fill in a 0 50

51 Requirements negotiation Disagreements about requirements are inevitable when a system has many stakeholders. Conflicts are not failures but reflect different stakeholder needs and priorities Requirements negotiation is the process of discussing requirements conflicts and reaching a compromise that all stakeholders can agree to In planning a requirements engineering process, it is important to leave enough time for negotiation. Finding an acceptable compromise can be timeconsuming 51

52 Negotiation meetings An information stage where the nature of the problems associated with a requirement is explained. A discussion stage where the stakeholders involved discuss how these problems might be resolved. All stakeholders with an interest in the requirement should be given the opportunity to comment. Priorities may be assigned to requirements at this stage. A resolution stage where actions concerning the requirement are agreed. These actions might be to delete the requirement, to suggest specific modifications to the requirement or to elicit further information about the requirement. 52

53 Key points Requirements elicitation involves understanding the application domain, the specific problem to be solved, the organisational needs and constraints and the specific facilities needed by system stakeholders. The processes of requirements elicitation, analysis and negotiation are iterative, interleaved processes which must usually be repeated several times. There are various techniques of requirements elicitation which may be used including interviewing, scenarios, soft systems methods, prototyping and participant observation. 53

54 Key points Prototypes are effective for requirements elicitation because stakeholders have something which they can experiment with to find their real requirements. Checklists are particularly useful as a way of organizing the requirements validation process. They remind analysts what to look for when reading through the proposed requirements. Requirements negotiation is always necessary to resolve requirements conflicts and remove requirements overlaps. Negotiation involves information interchange, discussion and resolution of disagreements. 54

55 Analysis checks Necessity checking The need for the requirement is analysed. In some cases, requirements may be proposed which don t contribute to the business goals of the organisation or to the specific problem to be addressed by the system. Consistency and completeness checking The requirements are cross-checked for consistency and completeness. Consistency means that no requirements should be contradictory; completeness means that no services or constraints which are needed have been missed out. Feasibility checking The requirements are checked to ensure that they are feasible in the context of the budget and schedule available for the system development. 55

56 Requirements negotiation Requirements discussion Requirements which have been highlighted as problematical are discussed and the stakeholders involved present their views about the requirements. Requirements prioritisation Disputed requirements are prioritised to identify critical requirements and to help the decision making process. Requirements agreement Solutions to the requirements problems are identified and a compromise set of requirements are agreed. Generally, this will involve making changes to some of the requirements. 56

57 Analysis and validation Analysis works with raw requirements as elicited from the system stakeholders Have we got the right requirements is the key question to be answered at this stage Validation works with a final draft of the requirements document i.e. with negotiated and agreed requirements Have we got the requirements right is the key question to be answered at this stage 57

58 Validation inputs and outputs R e q u i r e m e n t s d o c u m e n t O r g a n i s a t i o n a l k n o w l e d g e O r g a n i s a t i o n a l s t a n d a r d s R e q u ir e m e n t s v a l i d a t i o n L i s t o f p r o b l e m s A g r e e d a c t i o n s 58

59 59

60 Validation inputs Requirements document Should be a complete version of the document, not an unfinished draft. Formatted and organised according to organisational standards Organisational knowledge Knowledge, often implicit, of the organisation which may be used to judge the realism of the requirements Organisational standards Local standards e.g. for the organisation of the requirements document 60

61 Validation outputs Problem list List of discovered problems in the requirements document Agreed actions List of agreed actions in response to requirements problems. Some problems may have several corrective actions; some problems may have no associated actions 61

62 Requirements review process A group of people read and analyse the requirements, look for problems, meet and discuss the problems and agree on actions to address these problems P l a n r e v i e w D i s t r i b u t e d o c u m e n t s P r e p a r e f o r r e v i e w H o l d r e v i e w m e e ti n g F o ll o w - u p a c t i o n s R e v i s e d o c u m e n t 62

63 Review activities Plan review The review team is selected and a time and place for the review meeting is chosen. Distribute documents The requirements document is distributed to the review team members Prepare for review Individual reviewers read the requirements to find conflicts, omissions, inconsistencies, deviations from standards and other problems. 63

64 Review activities Hold review meeting Individual comments and problems are discussed and a set of actions to address the problems is agreed. Follow-up actions The chair of the review checks that the agreed actions have been carried out. Revise document The requirements document is revised to reflect the agreed actions. At this stage, it may be accepted or it may be re-reviewed 64

65 Requirements clarification Problem actions The requirement may be badly expressed or may have accidentally omitted information which has been collected during requirements elicitation. Missing information Some information is missing from the requirements document. It is the responsibility of the requirements engineers who are revising the document to discover this information from system stakeholders. Requirements conflict There is a significant conflict between requirements. The stakeholders involved must negotiate to resolve the conflict. Unrealistic requirement The requirement does not appear to be implementable with the technology available or given other constraints on the system. Stakeholders must be consulted to decide how to make the requirement more realistic. 65

66 Pre-review checking Reviews are expensive because they involve a number of people spending time reading and checking the requirements document This expense can be reduced by using pre-review checking where one person checks the document and looks for straightforward problems such as missing requirements, lack of conformance to standards, typographical errors, etc. Document may be returned for correction or the list of problems distributed to other reviewers 66

67 Pre-review checking C h e c k d o c u m e n t s t r u c t u r e C h e c k d o c u m e n t c o m p l e t e n e s s C h e c k d o c u m e n t a g a i n s t s t a n d a r d s R u n a u t o m a t i c c h e c k e r s R e q u ir e m e n t s d o c u m e n t P r o b l e m r e p o r t 67

68 Review team membership Reviews should involve a number of stakeholders drawn from different backgrounds People from different backgrounds bring different skills and knowledge to the review Stakeholders feel involved in the RE process and develop an understanding of the needs of other stakeholders Review team should always involve at least a domain expert and an end-user 68

69 Review checklists Understandability Can readers of the document understand what the requirements mean? Redundancy Is information unnecessarily repeated in the requirements document? Completeness Does the checker know of any missing requirements or is there any information missing from individual requirement descriptions? Ambiguity Are the requirements expressed using terms which are clearly defined? Could readers from different backgrounds make different interpretations of the requirements? 69

70 Review checklists Consistency Do the descriptions of different requirements include contradictions? Are there contradictions between individual requirements and overall system requirements? Organisation Is the document structured in a sensible way? Are the descriptions of requirements organised so that related requirements are grouped? Conformance to standards Does the requirements document and individual requirements conform to defined standards? Are departures from the standards, justified? Traceability Are requirements unambiguously identified, include links to related requirements and to the reasons why these requirements have been included? 70

71 Checklist questions Is each requirement uniquely identified? Are specialised terms defined in the glossary Does a requirement stand on its own or do you have to examine other requirements to understand what it means? Do individual requirements use the terms consistently Is the same service requested in different requirements? Are there any contradictions in these requests? If a requirement makes reference to some other facilities, are these described elsewhere in the document? Are related requirements grouped together? If not, do they refer to each other? 71

72 Types of Non-functional requirements The IEEE-Std lists 13 non-functional requirements to be included in a Software Requirements Document. Performance requirements Interface requirements Operational requirements Resource requirements Verification requirements Acceptance requirements Documentation requirements Security requirements Portability requirements Quality requirements Reliability requirements Maintainability requirements Safety requirements 72

73 Classification of NFRs Non-functional requirements Process requirements Delivery requirements implementation requirements standards requirements Product requirements Usability requirements Reliability requirements Safety requirements Efficiency requirements Performance requirements Capacity requirements External requirements Legal constraints Economic constraints Interoperability requirements 73

74 Requirements management The process of managing change to the requirements for a system The principal concerns of requirements management are: Managing changes to agreed requirements Managing the relationships between requirements Managing the dependencies between the requirements document and other documents produced in the systems engineering process Requirements cannot be managed effectively without requirements traceability. A requirement is traceable if you can discover who suggested the requirement, why the requirement exists, what requirements are related to it and how that requirement relates to other information such as systems designs, implementations and user documentation. 74

75 Requirements change factors Requirements errors, conflicts and inconsistencies As requirements are analysed and implemented, errors and inconsistencies emerge and must be corrected. These may be discovered during requirements analysis and validation or later in the development process. Evolving customer/end-user knowledge of the system As requirements are developed, customers and endusers develop a better understanding of what they really require from a system. Technical, schedule or cost problems Problems may be encountered in implementing a requirement. It may be too expensive or take too long to implement certain requirements. 75

76 Requirements change factors Changing customer priorities Customer priorities change during system development as a result of a changing business environment, the emergence of new competitors, staff changes, etc. Environmental changes The environment in which the system is to be installed may change so that the system requirements have to change to maintain compatibility Organisational changes The organisation which intends to use the system may change its structure and processes resulting in new system requirements 76

77 Requirements identification It is essential for requirements management that every requirement should have a unique identification The most common approach is requirements numbering based on chapter/section in the requirements document Example: Symbolic identification Requirements can be identified by giving them a symbolic name which is associated with the requirement itself. For example, EFF-1, EFF- 2, EFF-3 may be used for requirements which relate to system efficiency 77

78 The change management process Some requirements problem is identified. This could come from an analysis of the requirements, new customer needs, or operational problems with the system. The requirements are analysed using problem information and requirements changes are proposed. The proposed changes are analysed This checks how many requirements (and, if necessary, system components) are affected by the change and roughly how much it would cost, in both time and money, to make the change. The change is implemented. A set of amendments to the requirements document or a new document version is produced. This should, of course, be validated using whatever normal quality checking procedures are used. 78

79 Change management stages I d e n t i f i e d p r o b l e m P r o b l e m a n a l y s i s a n d c h a n g e s p e c i f i c a t i o n C h a n g e a n a l y s i s a n d c o s t i n g C h a n g e i m p l e m e n t a t i o n R e v i s e d r e q u i r e m e n t s Change Change rejected rejected 79

80 Traceability Traceability information is information which helps you assess the impact of requirements change. It links related requirements and the requirements and other system representations Types of traceability information B u s i n e s s p l a n R e q u ir e m e n t s D o c u m e n t D e s i g n S p e c i f i c a t i o n F o r w a r d - t o t r a c e a b i l i t y F o r w a r d - f r o m t r a c e a b i l i t y B a c k w a r d - f r o m t r a c e a b i l i t y B a c k w a r d - t o t r a c e a b i l i t y 80

81 Requirements document The requirements document is a formal document used to communicate the requirements to customers, engineers and managers. The requirements document describes: The services and functions which the system should provide The constraints under which the system must operate Overall properties of the system i.e.. constraints on the system s emergent properties Definitions of other systems which the system must integrate with. 81

82 Requirements document The requirements document describes: Information about the application domain of the system e.g. how to carry out particular types of computation Constraints on the processes used to develop the system Description of the hardware on which the system is to run In addition, the requirements document should always include an introductory chapter which provides an overview of the system, business needs supported by the system and a glossary which explains the 82 terminology used.

83 Users of requirements documents System customers specify the requirements and read them to check they meet their needs Project managers Use the requirements document to plan a bid for system and to plan the system development process System engineers Use the requirements to understand the system being developed System test engineers Use the requirements to develop validation tests for the system System maintenance engineers Use the requirements to help understand the system 83

84 Requirements document structure IEEE/ANSI standard proposes a structure for software requirements documents Introduction 1.1 Purpose of requirements document 1.2 Scope of the product 1.3 Definitions, acronyms and abbreviations 1.4 References 1.5 Overview of the remainder of the document 84

85 Requirements document structure 2. General description 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 General constraints 2.5 Assumptions and dependencies 3. Specific requirements Covering functional, non-functional and interface requirements. 4. Appendices Index 85

86 Adapting the standard The IEEE standard is a generic standard which is intended apply to a wide range of requirements documents. In general, not all parts of the standard are required for all requirements documents Each organisation should adapt the standard depending on the type of systems it develops Consider a company (XYZ) that develops scientific instruments 86