Other Requirements

1. Other Requirements Chapter 7 Applying UML and Patterns Craig Larman

2. Introduction • Primary requirements of computer systems tend to be functional requirements • the list of activities that the system must perform to provide value to its users • Developers must also capture other non-functional system requirements • Non-functional requirements may be captured in: • Vision Statement • Glossary • Supplementary Specification.

3. Non-Functional Requirements Are Not a Checklist • Not a listing of things that have to be documented in a system • Documentation costs money and takes time. • Use only enough resources to produce the desired results efficiently and effectively.

4. Vision Statement • Communicates the project sponsor’s and key stakeholder’s… • reasons for the project • problems to be solved • description of stakeholders and their needs • description of the proposed solution • Vision Statement contains the core system requirements • It becomes the contractual basis to develop further requirements

5. Glossary • Captures terms and their definitions in the business domain • Terms may mean different things to different stakeholders and need to be defined. • Can also perform the role of a Data Dictionary, or be supplemented by one. • See example p. 115 in textbook

6. Supplementary Specification • Captures requirements such as documentation, supportability, packaging, licensing.

7. Supplementary Specification Contents • Common Functionality • Logging • Error Handling • Business Rules • Security • Usability • Reliability • Recoverability • Performance • Supportability • Adaptability • Configurability • Implementation Constraints • Purchased Components

8. More Supplementary Specifications • Interfaces • Hardware • Software • Domain Rules • Legal Issues • Reports • Operating Systems • Networking Systems • Process Tools • Development Tools • Design Constraints • Internationalization • Standards • Physical Environment • Operation Rules

9. Domain or Business Rules • Are not functional requirements. • Describe how the business works, while functional requirements tell how the system works. • Company policies and government regulations are examples

10. UML Diagrams in Inception • Aside from the possible inclusion of a few high level use case diagrams, the inception phase is almost all text. • Most diagramming occurs in the Elaboration Phase.

11. From Inception to Elaboration Chapter 8 Applying UML and Patterns Craig Larman

12. Inception - Artifacts and Activities • Requirements workshop • Name actors, goals, use cases • Keep use cases brief • Identify most risky & influential quality requirements • First version of Supplementary Specification and Vision Statement

13. Inception - Artifacts and Activities • Risk list • Technical feasibility • UI oriented prototypes • Buy/build/reuse components • High-level candidate architecture • Plan first iteration • Candidate tools list

14. Elaboration - Key Ideas • Not a waterfall model ! • Two to six weeks for each iteration • Timeboxed iterations • Each iteration ends in a stable and tested release

15. Best Practices • Start programming early • Adapt based on feedback • Design, implement, and test adaptively • Test early and realistically • Determine requirements and use case details through a series of workshops

16. UP Elaboration Artifacts • Domain Model – visualization of domain concepts and relationships • Design Model – diagrams of logical design • (e.g. software class and package diagrams) • Software Architecture Document – summary of key architectural issues • Data Model – database schemas and relational/object mapping strategies • UI Prototypes – user interface

17. Elaboration “Fails” When… • No Timeboxed schedule - only one Iteration • No Risk mitigation/resolution • No Executable Architecture • Minimal feedback and adaptation • No early and realistic testing • No Proof-of-concept programming