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

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.

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.

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 Key vision questions: Problem Statement Key High Level Goals Key Problems for the Stakeholders What are the root problems and goals?

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

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

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

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

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

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.

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

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

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

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

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

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

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