1. Chapter 7 Applying UML and Patterns Craig Larman
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
Key vision questions:
Problem Statement
Key High Level Goals
Key Problems for the Stakeholders
What are the root problems and goals?

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