Identificering af øvrige krav

1. Identificering af øvrige krav Larman kap.7 Larman kap. 7

2. Supplementary specification, vision and glossary Larman kap. 7

3. Øvrige krav omhandler : • Supplementary specification • Omhandler de krav der ikke er beskrevet i usecases. • Vision • Beskrivelse af visionen for projektet. • En koncentreret fremstilling af hoved ideerne i projektet. • Glossary • Definition af begreber. Larman kap. 7

4. Supplementary specification • Omhandler øvrige krav end dem der er beskrevet i usescases, f.eks. : • Bl.a. URPS+ (usability, reliability, performance, supportability) • Rapporter • HW og SW begrænsninger • Udviklingsbegrænsninger (proces, værktøjer) • Internationalisering • Dokumentation • Standarder • Det fysiske miljø (varme, vibrationer..) • Domæne eller forretningsregler • Licensregler ….. • Krav der relaterer sig specifikt til en usecase beskrives i usecasen (Special requirements afsnittet) Larman kap. 7

5. Kategorisering af krav • FURPS+ modellen : • Functionality • Usability • Grænseflade, hjælp, dokumentation • Reliability • Fejlfrekvens, recoverbility… • Performance • Response time, resurce forbrug… • Supportability • Adaptability, maintainability, internationalization Larman kap. 7

6. Kategorisering af krav • + i FURPS+ (alt andet…) • Design constraints • Implementation requirements • Interface requirements • Physical requirements Larman kap. 7

7. Supplementary specification Quality attributes: • Observable at execution(functionality, usability, reliability, performance, …) • Not observable at execution(supportability, testability, …) Larman kap. 7

8. Supplementary specification • S. 84 -87 Larman kap. 7

9. Vision • The Vision defines the stakeholders view of the product to be developed, specified in terms of the stakeholders key needs and features. Containing an outline of the envisioned core requirements, it provides the contractual basis for the more detailed technical requirements. Larman kap. 7

10. Vision • The Vision captures very high-level requirements and design constraints to give the reader an understanding of the system to be developed. • It provides input to the project-approval process and is, therefore, intimately related to the Business Case. It communicates the fundamental "whys and what's" related to the project and is a gauge against which all future decisions should be validated. • The Vision document will be read by managers, funding authorities, roles in use-case modeling, and developers in general. Larman kap. 7

11. Vision • Page 91 - 93 Larman kap. 7

12. Vision Problem statement (domain problem): the problem of …………. affects ……………… the impact of which is …………… a successful solution would be ………. Larman kap. 7

13. Vision System features: • High-level, terse statements summarizing system functions • “the system shall do <feature X>” (the system shall do payment authorization) Larman kap. 7

14. Suggested sequence • Write a brief first draft of the vision • Identify user goals and the supporting use cases • Write some use cases and start the Supplementary Specification • Refine the vision, summarizing information from these Larman kap. 7

15. Glossary • a list of noteworthy terms and their definitions • Name • Aliases • Description • Format (type, length, unit) • Relationships to other elements • Range of values • Validation rules Larman kap. 7

16. Glossary • Page 98 - 99 Larman kap. 7

17. Other requirements and UP • S. 102 (tabel 7.1) Larman kap. 7

18. When, where, who, how ? Larman kap. 7