it requirements capture process
DESCRIPTION
IT Requirements Capture Process. 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. Traditional requirement specs. - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: IT Requirements Capture Process](https://reader035.vdocuments.us/reader035/viewer/2022062811/568160e2550346895dd0116f/html5/thumbnails/1.jpg)
IT Requirements Capture Process
![Page 2: IT Requirements Capture Process](https://reader035.vdocuments.us/reader035/viewer/2022062811/568160e2550346895dd0116f/html5/thumbnails/2.jpg)
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.
![Page 3: IT Requirements Capture Process](https://reader035.vdocuments.us/reader035/viewer/2022062811/568160e2550346895dd0116f/html5/thumbnails/3.jpg)
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
![Page 4: IT Requirements Capture Process](https://reader035.vdocuments.us/reader035/viewer/2022062811/568160e2550346895dd0116f/html5/thumbnails/4.jpg)
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
![Page 5: IT Requirements Capture Process](https://reader035.vdocuments.us/reader035/viewer/2022062811/568160e2550346895dd0116f/html5/thumbnails/5.jpg)
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
![Page 6: IT Requirements Capture Process](https://reader035.vdocuments.us/reader035/viewer/2022062811/568160e2550346895dd0116f/html5/thumbnails/6.jpg)
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
![Page 7: IT Requirements Capture Process](https://reader035.vdocuments.us/reader035/viewer/2022062811/568160e2550346895dd0116f/html5/thumbnails/7.jpg)
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.
![Page 8: IT Requirements Capture Process](https://reader035.vdocuments.us/reader035/viewer/2022062811/568160e2550346895dd0116f/html5/thumbnails/8.jpg)
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
![Page 9: IT Requirements Capture Process](https://reader035.vdocuments.us/reader035/viewer/2022062811/568160e2550346895dd0116f/html5/thumbnails/9.jpg)
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
![Page 10: IT Requirements Capture Process](https://reader035.vdocuments.us/reader035/viewer/2022062811/568160e2550346895dd0116f/html5/thumbnails/10.jpg)
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
![Page 11: IT Requirements Capture Process](https://reader035.vdocuments.us/reader035/viewer/2022062811/568160e2550346895dd0116f/html5/thumbnails/11.jpg)
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
![Page 12: IT Requirements Capture Process](https://reader035.vdocuments.us/reader035/viewer/2022062811/568160e2550346895dd0116f/html5/thumbnails/12.jpg)
An Adaptive Process
Develop business model
Define actors &
architecture
Write use case
reports
Revise
Extract functional
requirements
Capture nonfunctional requirements
Develop supplementary requirements
Σ Requirements Specification
Vision, Ops &
Capabilities
The new part.
![Page 13: IT Requirements Capture Process](https://reader035.vdocuments.us/reader035/viewer/2022062811/568160e2550346895dd0116f/html5/thumbnails/13.jpg)
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.
![Page 14: IT Requirements Capture Process](https://reader035.vdocuments.us/reader035/viewer/2022062811/568160e2550346895dd0116f/html5/thumbnails/14.jpg)
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
![Page 15: IT Requirements Capture Process](https://reader035.vdocuments.us/reader035/viewer/2022062811/568160e2550346895dd0116f/html5/thumbnails/15.jpg)
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.
![Page 16: IT Requirements Capture Process](https://reader035.vdocuments.us/reader035/viewer/2022062811/568160e2550346895dd0116f/html5/thumbnails/16.jpg)
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
![Page 17: IT Requirements Capture Process](https://reader035.vdocuments.us/reader035/viewer/2022062811/568160e2550346895dd0116f/html5/thumbnails/17.jpg)
Rating the requirements methods*
Criterion Shall
Statement Method
Use Cases
Hybrid Process
Necessary 1 3 3 Verifiable 3 1 3 Unambiguous 3 2 3 Complete 2 3 3 Consistent 1 2 3 Traceable 2 2 3 Concise 3 1 3 Standard constructs
3 1 3
1= poor, 3= good
![Page 18: IT Requirements Capture Process](https://reader035.vdocuments.us/reader035/viewer/2022062811/568160e2550346895dd0116f/html5/thumbnails/18.jpg)
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.
![Page 19: IT Requirements Capture Process](https://reader035.vdocuments.us/reader035/viewer/2022062811/568160e2550346895dd0116f/html5/thumbnails/19.jpg)
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.