Post on 20-Mar-2017
Software Engineering ProcessDisciplined, Modern, and Mature
An Overview Workshop for the Railroad Commission of Texas
January 21 & 22, 2003
Project InceptionProject Inception
Vision Artifact
• The Vision defines the stakeholders view of the product to be developed, specified in terms of the stakeholders key needs and features
• It contains an outline of the envisioned core requirements, it provides the contractual basis for the more detailed technical requirements
• Typically, the approval of the Vision document is a prerequisite for moving forward with the project
Project InceptionProject Inception
Group Discussion - Vision
• Discuss the types of ‘Vision’ Artifacts used by the RRC to launch a project
• Is there an organizational standard or does it vary from project to project?
• Review the STARS Project Management Plan• Review the Vision Template in RUP
Requirements Requirements ManagementManagement
Introduction
• Managing requirements involves the translation of stakeholder requests into a set of key stakeholder needs and system features
• These, in turn, are detailed into specifications for functional and non-functional requirements
• Functional requirements are then detailed into use case specifications (system or report), which are the basis for system design, implementation, system testing, and user documentation
Requirements Requirements ManagementManagement
Needs
Features
Software Requirements
System DesignImplementation System Testing
User Documentation
Problem ProblemSpace
SolutionSpace
Trac
eabi
lity
ProductTo BeBuilt
Requirements Requirements ManagementManagement
Functional and Nonfunctional Requirements
• Functional Requirements express how the system behaves
• These requirements are usually action oriented• More often than not, Functional Requirements
can be stated in simple declarative statements (i.e., shall/will/must statements)
• Most functional requirements can be stated in a one- or two-statement sentence
Requirements Requirements ManagementManagement
Functional and Nonfunctional Requirements
• While Functional Requirements are important, they cannot fully capture the requirements of the system
• To complete the description of the system, Nonfunctional Requirements are required
• Nonfunctional Requirements typically express some of the “attributes of the system” or “attributes of the system environment”
Requirements Requirements ManagementManagement
Functional and Nonfunctional Requirements
• Nonfunctional Requirements are also stated in simple declarative statements (i.e., shall/will/must statements)
• Nonfunctional Requirements include states that describes the systems: Usability Reliability Performance Supportability
Requirements Requirements ManagementManagement
Nonfunctional Requirements
• Usability requirements describe the ease with which the system can be learned and operated by the intended users
• Reliability describe the degree to which the system must behave in a user-acceptable fashion Availability (24 hours a day, 7 days a week) Mean time between failures Mean time to repair Defect rates, maximum bugs, bugs per type
Requirements Requirements ManagementManagement
Nonfunctional Requirements
• Performance requirements usually cover such categories as: Transaction response times Throughput, or transactions per second Capacity, or the number of customers or
transactions the system can support (i.e., workload)
• Supportability is the ability of the software to be easily modified to accommodate change
Requirements Requirements ManagementManagement
Requirement Types (FURPS+)
• Functionality• Usability• Reliability• Performance• Supportability• + - indicates that there are more possible
categories to be considered as required by any given project
Requirements Requirements ManagementManagement
Requirements and Use Cases Exercise – Part 1
• Organize into the groups formed yesterday• Using the Railroad Commission Requirements
and Use Cases Exercise, review each requirement as a team and identify the requirement as either Functional on Nonfunctional
• Note the team’s decision on the exercise sheet• Each team member should do the same on their
individual sheets• Each team will then report to the group
Requirements Requirements ManagementManagement
Software Requirements Specification
• The Software Requirements Specification (SRS) captures the complete software requirements for the system
• When using use-case modeling, this deliverable includes both the use cases within the Use Case Model as well as the Nonfunctional Requirements documented in the project’s Supplementary Specification
Requirements Requirements ManagementManagement
Requirements Management Discussion
• Discuss JRP Sessions – a requirements elicitation techniques
• Review the STARS Requirements Traceability Matrix and note the logical grouping of requirements
• Review the STARS Software Requirements Specification and STARS Supplementary Specification
• Review the SRS Template in RUP
Requirements Requirements ManagementManagement
Stakeholders’ Requests
Features
Use Cases Supplementary
Functional
Requirements
Nonfunctional
Requirements
ResourcesResources
Dean Leffingwell and DonWidrig (2000). Managing Software Requirements A Unified Approach. Addison-Wesley Publishing Company, Inc.
Use Case ModelingUse Case Modeling
What is Use Case Modeling?
• A means for capturing the desired behavior for the system under development
• A way to communicate the system’s behavior• Identifies who or what interacts with the system
and what the system should do• A way to verify all requirements are captured• A planning instrument
Use Case ModelingUse Case Modeling
Benefits of Use Cases
• Give context to requirements• Are easy to understand• Facilitate agreement with customer regarding
the required behavior of the system• A way to verify all requirements are captured• A planning instrument
Use Case ModelingUse Case Modeling
Actors and Use Cases
• Actor Someone or something outside the system that interacts with the system
• Use CaseWhat an actor wants to use the system to do
Use Case ModelingUse Case Modeling
What is a Use Case?
• Defines a sequence of actions Atomic activities, decisions, and requests
• Performed by the systemThe actions performed by the system are the functional requirements
• That yields an observable result of valuePost-Condition – ensures that the use case results in an observable value
• To the actor
Use Case ModelingUse Case Modeling
What is a Use Case?
• To the actor Deciding which particular actor receives the value helps avoid use cases that are too large
Often the sequence of interactions in a use case involves several actors, but only one actor receives the value of the result
This is usually the actor who initiates the use case (or the primary actor)
Use Case ModelingUse Case Modeling
Steps to Create a Use Case Model
• Identify actors and use cases• Outline each use case• Detail each use case• Structure each use case’s flow of eventsNote: Similar to the actual software application,
use cases are often refined over multiple iterations as the project team learns more about the intended system
Use Case ModelingUse Case Modeling
Group Exercise - Actors
• Using a brainstorming technique, lets identify the actors for a proposed RRC project
• Remember, actors are external to the system and initiate, or communicate, with the system
• Following this activity, lets again review the Course Registration System’s Use Case Model and the STARS Use Case Model
Use Case ModelingUse Case Modeling
Use Case Pattern
• Earlier we discussed organizing your functional requirements into logical groupings(Note: this also applies to nonfunctional requirements in terms of URPS)
• Each group was referred to as a high-level feature
• The next step in the process is identifying the use case(s) that will be required to support your functional requirements
Use Case ModelingUse Case Modeling
Use Case Pattern
• As you may imagine, this can be rather challenging at first
• To assist you in this effort, I will offer for your consideration the use case pattern that we applied on the STARS Project
• This use case pattern is based upon the understanding that there are certain types of tasks that typically occur within any given software application
Use Case ModelingUse Case Modeling
Use Case Pattern
• General Types of Use Cases Maintain Process View Generate Report
Use Case ModelingUse Case Modeling
Use Case Pattern
• Maintain Use Cases This type of use case supports maintaining of
system information These are CRUD (i.e., create, read, update,
and delete) type use cases The thing of value that this type of use case
supplies is making data persistent, typically in a relational database management system (RDBMS)
Use Case ModelingUse Case Modeling
Use Case Pattern
• Process Use Cases This type of use case supports analytical
processes While some information that results from the
analysis is made persistent, the primary purpose for the use case is supporting analytical processes
The thing of value that this type of use case supplies is its support for an analytical process and making analysis data persistent
Use Case ModelingUse Case Modeling
Use Case Pattern
• View Use Cases This type of use case supports the searching
and viewing of information Nearly every system will require this
functionality The thing of value that this type of use case
supplies is the viewing of information, whether in a report or as the result of a search, which actually is a type of report
Use Case ModelingUse Case Modeling
Use Case Pattern
• Generate Use Cases This type of use case supports the generation
of a data file from system information If the system must supply data to other
entities or legacy systems, this type of use case will be needed
The thing of value that this type of use case supplies is the generation of a data file external to the system
Use Case ModelingUse Case Modeling
Use Case Pattern
• Report Use Cases This type of use case supports all of your
report requirements Nearly every system has report requirements While a ‘View a Report’ Use Case supports
the viewing of a report, this type of use case is the report itself
The thing of value that this type of use case supplies is the report
Requirements Requirements ManagementManagement
Requirements and Use Cases Exercise – Part 2
• Organize into your groups• Using the Railroad Commission Requirements
and Use Cases Exercise, review each functional requirement as a team and identify the type of use case (i.e., maintain, process, view, generate, or report) that will be required to support the requirement
• Note the team’s decision on the exercise sheet
Requirements Requirements ManagementManagement
Requirements and Use Cases Exercise – Part 2
• Each team member should do the same on their individual sheets
• Each team will then report to the group
Use Case ModelingUse Case Modeling
Use Case Structure
• There are many documented ways to structure a use case
• The reason for this is that the art and science of use cases is evolving; it is in process
• What follows is the structure of the use cases created by the STARS Project Development Team
Use Case ModelingUse Case Modeling
System Use Case Structure
• Business ContextThis use case is used when the actor . . .
• Pre-ConditionsWhat must be true before the use case can be executed
• OverviewThis use case enables the actor . . .The use case ends . . .
Use Case ModelingUse Case Modeling
System Use Case Structure
• Flow of Events Primary Flow Alternate Flow Warning Flow Exception Flow
• Post-ConditionsIdentifies the thing of value the use case provides to the actor
Use Case ModelingUse Case Modeling
System Use Case Structure
• Non-Functional RequirementsSecurity, etc.
• Use Interface RequirementsUser experience prototypesNote: Will be replaced in Design by the User Interface Design Document
• Design CommentsScratch pad for capturing design considerations discovered throughout the lifecycle and specific to the use case
Use Case ModelingUse Case Modeling
Report Use Case Structure
• The STARS Project Development Team also created over 100 report use cases
• While the report use case structure is the same, there are some variations specific to reports
• Report Specific Considerations Report Title Report Body Report Specifications Chart Presentation
Use Case ModelingUse Case Modeling
Use Case Tips
• Describe only the events visible to the actor What the actor does What the system does in response
• Make use cases provide value to the actor who initiated the use case
• Detail until everyone (i.e., your customer) has a common understanding of the requirements
• Use agreed-upon terms and vocabulary• Use precise language
Use Case ModelingUse Case Modeling
Avoid Functional Decomposition
• Functional decomposition is the breaking down of a problem into small isolated parts
• The parts: Work together to provide the functionality of
the system Often do not make sense in isolation
• Use Cases: Are not functional decomposition
Use Case ModelingUse Case Modeling
Avoid Functional Decomposition
• Functional decomposition is the breaking down of a problem into small isolated parts
• The parts: Work together to provide the functionality of
the system Often do not make sense in isolation
• Use Cases: Use Case describe the complete use of the
system to achieve a goal
Use Case ModelingUse Case Modeling
Use Case Names
• Use case should be named consistent with the business process it is supporting
• The name should be meaningful to you the business owner of the software application
• Use an active verb in the use case name to reflect the value the use case provides to the actor
Group Activity
• Review STARS System Use Case Template• Review STARS Report Use Case Template• Review sample STARS System Use Cases• Review sample STARS Report Use Cases
Use Case ModelingUse Case Modeling