IT Requirements Capture Process

1. IT Requirements Capture Process

2. Motivation for this seminar • Discovering system requirements is hard. • Formally testing use case conformance is hard. • We wanted to show that use cases and shall-statement requirements can be applied synergistically.

3. Traditional requirement specs • Requirements are documented as distinct, textual statements of imperative • Usually using “shall-statement” notation • Typically organized by functional area • Requirements are structured into parent-child relationships to facilitate requirement decomposition and derivation

4. Traditional specs, strengths • Allows for very precise wording • Straightforward “sign off” of capabilities during testing • Important for defense contracts • Requirements easily captured in a tool (e.g., database) • Widely known and accepted, especially in the defense industry

5. Traditional specs, weaknesses • Often become very long and tedious • Increases chance of ambiguity • Hard to comprehend the entire set • Difficult to review with customers • Little context to each requirement • Typically nothing that “ties” requirements together into a comprehensive story

6. Use cases • Originated in the software industry • Focus: “What does my system have to do for each user type” • Describes system functionality through structured narrative stories • Provides light graphical modeling via UML use case diagrams

7. Use cases • A use case is an abstraction of a required behavior of a system. • A use case produces an observable result of value to the user. • A typical system will have many use cases each of which satisfies a goal of a particular user. • Each use case describes a sequence of interactions between one or more actors and the system. • A use case narrative is written in a natural language. It is written as a sequence of numbered steps with a main success scenario and alternate flows. • This sequence of interactions is contained in a use case report and the relationships between the system and its actors are portrayed in use case diagrams.

8. Use cases, strengths • Simple concept • Easy to comprehend and follow • Contingent on writing skill, of course! • User focused – ensures that you consider how the system supports its environment • Easy to review with non-technical stakeholders

9. Use cases, weaknesses • Lack precision • Use cases feel vague • Relatively hard to document and organize lots of necessary details • Use cases are not fully accepted • Hard to definitively “sign off” a use case for acceptance testing

10. Two requirements specification methods • Shall-Statement Requirements • Precise and widely accepted but specs are typically long and hard to comprehend as a set • Use Cases • Simple and ensure the system satisfies user needs but are less precise and hard to formally test

11. The starting point • Capture non-functional requirements in shall-statement form directly in use case report • Use a “supplementary specification” to capture global non-functional requirements

12. An Adaptive Process The new part.

13. An Adaptive process that combines traditional requirements and use cases • Develop a business model • Discover the actors and their goals • Sketch out the use case reports • Iterate on the architecturally significant use cases Extract the functional requirements from each use case's Brief Description, Added Value and Flow of Events and document them in the Specific Requirements Sections • Document the nonfunctional requirements in the Specific Requirements Sections • Iterate on the use case set to ensure consistency and completeness • Develop a Supplementary Requirements Specification to capture system-wide requirements that do not fit into individual use case reports.

14. Uses of process output • With the shall-statement requirements a traditional requirements spec can be easily created • Requirements are based on use cases – good traceability to user goals • Can be stored in a database • Can build formal tests for each use case • Sign off shall-statements • Specific requirements section used to document details • Data requirements • User Interface preferences • Constraints • These details clutter scenario narrative

15. Requirements and use cases • Specific Requirements • Functional requirements state, in formal shall statement notation, the functions that the system must execute. • Nonfunctional requirements are often performance requirements that specify how well the system must execute certain functions. • Supplementary Requirements Specification contains the requirements that are associated with more than one use case. Often they are system wide. Examples include cost, schedule, reliability, availability, technology, design life, etc.

16. Goals versus requirements • The Mission Statement, Concept of Operations and Business Model contain goals, objectives, capabilities, features, constraints and top-level functions. • Formal requirements are contained in • Specific Requirements Sections of the Use Cases • Supplementary Requirements Specification • Traditional Requirements Specification

17. Rating the requirements methods* 1= poor, 3= good

18. Critique of the process • A problem with the these Processed is that it produces specific, low-level, design requirements. • We do not know if these can be abstracted to high-level customer requirements. • The Brief Description and Added Value slots of the use case might provide high-level requirements. • We need examples of using the process with business use cases.

19. Summary • The process derive statement requirements from the use case sequence of events. • These functional requirements are put in the Specific Requirements section of the use case report. • These functional requirements can then be put into a requirements database to support traditional specs and tracing.