Post on 19-Dec-2015
1
Software Requirement AnalysisDeployment Packagefor the Basic Profile
Version 0.1, January 11th 2008
2
Agenda
1. Introduction
2. Definitions
3. Components of a Process Description
4. Overview of the Process
5. Walkthrough of the Process
6. Templates
7. Examples
8. Checklist
9. Tool
10. Compliances Matrices
3
Introduction
• Purpose of this Package– Implement a good customer requirements management and
analysis process in their company.
4
Introduction• In IT projects, it is critical to define as unambiguously as possible
the customer requirements.– Close to 50% of the defects are produced during the requirements phase.
System Development Phase
Defects
Selby, P., Selby, R.W., Measurement-Driven Systems Engineering Using Six Sigma Techniques to Improve Software Defect Detection, Proceedings of 17th International Symposium, INCOSE, June 2007, San Diego.
5
Definitions• Task
– A requirement, recommendation, or permissible action, intended to contribute to the achievement of one or more outcomes of a process
– A task is composed of steps • Requirements analysis
– The process of studying user needs to arrive at a definition of system, hardware, or software requirements.
• Requirements document– A document containing any combination of recommendations, requirements or
regulations to be met by a software package.• Requirements phase
– The period of time in the software life cycle during which the requirements for a software product are defined and documented.
• Software Requirements Specifications (SRS):– Specification for a particular software product, program, or set of programs that
performs certain functions in a specific environment. – May be written by one or more representatives of the supplier, one or more
representatives of the customer, or by both. – Contains both functional and non functional requirements.– Can be materialized in a word document but it can also be managed in a database
or in a Excel file.
6
• Requirement– A statement that identifies what a product or process must accomplish to
produce required behaviour and/or results.
• Non Functional Requirement– A software requirement that describes not what the software will do but
how the software will do it.
• Prototype– An experimental model, either functional or non functional, of the system
or part of the system. – May serves as a model for later stages or for the final, complete version
of the system
Definitions
7
Components of a Process Description
• For each task, the following elements are described:– Objectives: key objectives of the task (e.g. understand customer
business processes)
– Rationale: explain why this task is important
– Steps: Steps that form the task (e.g. use case elicitation, coding,…)
– Roles: key roles involved in the task (e.g. analyst, developer, tester,…)*
– Artefact: piece of information or deliverable that can be produced (not mandatory) by one or several task. (e.g. design document, source code)
* Several roles can be played by a single person, especially in Very Small Enterprises.
8
Process Tasks
1. Requirements identification• The objective of this activity is to clearly define the scope of the
project and identify the key requirements of the system.
2. Requirements refinement and analysis• The objective of this Step is to detail and analyse all the
requirements identified.
3. Requirements verification & validation• Verify requirements and obtain validation from the customer or
his representative.
4. Requirements change management• To manage requirements change according with a process agreed
upon with the customer.
9
Process Roles– Analyst
– Person in charge within the development team to gather, analyze and manage the requirements related to the software to be developed.
– Customer– Person in charge within the customer side to transfer and
validate requirements to the development team. It can be the customer or any representative.
– Developer– Person in charge of the development of the software.
– Project Manager– Person in charge of managing the project (cost, schedule,
tasks, contract,…)
10
Process Artefacts (Outputs)
• Use Cases Scenarios– Description of a sequence of interactions between the user and the
future systems. Uses cases can be written as prescribed by UML but can also be text scenarios.
• Requirements Document – Document in which all identified requirements are centralized.
• Software prototype– Working piece of software produced during the early phases in
order to demonstrate/validate a functionality of a system.
11
Overview of the Process
12
Task 1. Requirements Identification
• Objectives• The objective of this activity is to clearly define the scope of the project and
identify the key requirements of the system.• Rationale
• It is important to clearly define the project scope (boundaries) and to identify key functionalities of the future system with the customer to avoid problems like forgotten key functionalities or requirements creep.
• Roles• Project Manager• Analyst
• Artefacts• Use Cases – scenarios• Requirements Document
• Steps1. Collect information about the application domain (e.g. finance, medical,…)2. Identify project’s scope3. Identify and capture requirements4. Structure and prioritize requirements
13
Task 2. Requirements Refinement and Analysis
• Objectives– The objective of this Step is to detail and analyse all the requirements
identified.• Rationale
– It is important to go through identified requirements in order to detect requirements that seem easy to implement but hiding a business complexity that will cause problems in the project.
• Roles– Analyst– Customer – Developer
• Artefacts– Use Cases – scenarios– Requirements Document – Software prototype
• Steps1. Detail requirements2. Produce a prototype
14
Task 3. Requirements Verification & Validation
• Objectives– Verify requirements and obtain validation from the customer or his
representative.• Rationale
– In order to avoid constant fundamental changes in the requirements, it is important to ask for the requirement validation from the customer.
• Roles– Analyst– Customer– Project Manager– Developer
• Artefacts– Requirements Document – Software prototype
• Steps1. Clarify fuzzy requirements (verification)2. Review software requirements specification3. Validate requirements
15
Task 4. Requirements Change Management
• Objectives– To manage requirements change according with a process agreed upon with
the customer.• Rationale
– Requirements change is a permanent feature of most of the IT projects. Change management must be planned and agreed upon with the customer on the project.
• Roles– Analyst– Project Manager– Customer
• Artefacts– Requirements Document
• Steps1. Track changes to requirements2. Analyze impact of changes3. Identify changes that are out of the project scope4. Prioritize changes
16
Templates
• Construx
• Volere
• IEEE Standard 830
17
Example 1- Requirement Lifecycle
• Short description here or in the Note page ?
18
Example 2 - Requirement Lifecycle
• Short description here or in the Note page ?
19
Requirements Checklist
RS 1 Testable All requirements are verifiable (objectively)
RS 2 Complete Are the requirements complete?
RS 3 Traceable All requirements must be traceable to a systems specification, contractual/proposal clause.
RS 4 Correct Requirements must be correct (i.e. reflect exactly customer’s requirements)
RS 5 Unique Requirements must be stated only once
RS 6 Elementary Requirements must be broken into their most elementary form
RS 7 Scope Are the requirements in scope?
RS 8 High Level Requirement must be stated in terms of final need, not perceived means (solutions)
RS 9 Quality Quality attributes have been defined.
RS 10 Unambiguous SRS must contain requirements statements that can be interpreted in one way only.
RS 11 Hardware Hardware environment is completely defined.
RS 12 Solid Requirements are a solid base for design
20
Support Tool
• Tracability Tool– To maintain the linkage from the source of each requirement through its decomposition
to implementation and test (verification). – To ensure that all requirements are addressed, and that only what is required is
developed. – Useful when conducting impact assessments of requirements, design or other configured
item changes. – Location of the tool
• address of web site: XXX
Unique Requirement
ID
Requirement Description
Design
Reference
Module / Configured Item
Reference
Release
Reference
Test Script Name/Step Number Reference
21
Compliances Matrices
• ISO 9001 Coverage Matrix
• ISO/IEC 12207 Coverage Matrix
• CMMI Coverage MatrixClause of CMMI Coverage
F/PTitle of the
Activity Comments
Clause of ISO 9001 CoverageF/P
Title of the Activity Comments
Xyz… X Requirements identification Step 1- Collect information
about the application domain
Clause of ISO/IEC 12207 CoverageF/P
Title of the Activity
Comments
22
Back-up Slides