Professional Documents
Culture Documents
SE-Unit-4-Requirement Analysis - Specification
SE-Unit-4-Requirement Analysis - Specification
Requirement
Analysis & Specification
Requirements analysis is hard
“The hardest single part What is Requirement Engineering?
“The seeds of major
of building a software
software disasters are Tasks and techniques that lead
system is deciding what
usually sown in the to an understanding of
to build. No part of the
first three months of requirements is called
work so cripples the
commencing the requirement engineering.
resulting system if done
software project.”
wrong.”
2
Requirement Engineering
It provides the appropriate mechanism for Requirements fall into two types
understanding Functional requirements Non-Functional requirements
Managing requirements
6
Requirements Engineering Tasks Cont.
4 Negotiation 5 Specification
8
Elicitation is the Hardest Part! Project Inception
Problems of scope During the initial project meetings, the
System boundaries are ill-defined following tasks should be accomplished
Customers will provide irrelevant
information Identify the project stakeholders
Problems of understanding These are the folks we should be talking to
Customers never know exactly what they Recognize multiple viewpoints
want Stakeholders may have different (and
Customers don’t understand capabilities and conflicting) requirements
limitations
Customers have trouble fully communicating
Work toward collaboration
needs It’s all about reconciling conflict
Problems of volatility Ask the first questions
Requirements always change Who? What are the benefits? Another source?
What is the problem? What defines success?
Other constraints?
Am I doing my job right?
9
Collaborative Elicitation Elicitation work products
Collaborative elicitation should result in several work
products
A bounded statement of scope A list of stakeholders
A description of the technical environment
A list of requirements and constraints
Any prototypes developed
A set of use cases
• Characterize how users will
One-on-one Q&A sessions interact with the system
rarely succeed in practice; • Use cases tie functional
collaborative strategies are requirements together
more practical
10
Quality Function Deployment (QFD)
This is a technique that translates the needs of the customer into technical requirements
for software
It emphasizes an understanding of what is valuable to the customer and then deploys these
values throughout the engineering process through functions, information, and tasks
It identifies three types of requirements
Normal requirements: These requirements are the objectives and goals stated for a product or
system during meetings with the customer
Expected requirements: These requirements are implicit to the product or system and may be so
fundamental that the customer does not explicitly state them
Exciting requirements: These requirements are for features that go beyond the customer's expectations
and prove to be very satisfying when present
11
The requirement analysis model
System
Establish the foundation for the software design Information
System Function
Provide a set of validation requirements
System Behaviors
12
Analysis rule of Thumb Elements of the Requirements Model
Make sure all points of view are Scenario-based Class Models
covered Models e.g.
Every element should add value e.g. Class diagrams
Use cases Collaboration
Keep it simple User Stories diagrams
Maintain a high level of
Software
abstraction Requirements
Focus on the problem domain
Minimize system coupling Behavioral Flow Models
Model should provide value to all Models e.g.
DFDs
stakeholders e.g.
Data models
State diagrams
Sequence diagrams
13
Elements of the Requirements Model Cont.
Scenario-based elements Behavioral elements
Describe the system from the user's point of view Use state diagrams to represent the state of the
using scenarios that are depicted (stated) in use system, the events that cause the system to change
cases and activity diagrams state, and the actions that are taken as a result of a
particular event. This can also be applied to each
Class-based elements class in the system.
Identify the domain classes for the objects Flow-oriented elements
manipulated by the actors, the attributes of these
classes, and how they interact with one another; Use data flow diagrams to show the input data that
which utilize class diagrams to do this. comes into a system, what functions are applied to
that data to do transformations, and what resulting
Use Case Activity Class output data are produced.
Diagram
Diagram Diagram Diagram
State
Data Flow
Diagram
14
Analysis Modeling Approaches
Structured Analysis Object Oriented Analysis
• Models data elements • Model analysis classes
⁻ Attributes ⁻ Data
⁻ Relationships ⁻ Processes
• Models processes that • Models class
transform data collaborations
15
SRS (Software Requirements Specification)
Software Requirement Specification (SRS) is a document that completely describes what the
proposed software should do without describing how software will do it.
SRS
Contains
A complete information description A detailed functional description
17
Characteristics of a Good SRS Cont.
Ranked for Modifiable
Importance/Stability
All requirements are not equally important, hence The requirements of the user can
each requirement is identified to make differences change, hence requirements
among other requirements. document should be created in such
Stability implies the probability of changes in the a manner that those changes can be
requirement in future. modified easily.
19
Standard Template for writing SRS
1. Introduction 3. System Features
1.1 Purpose 3.1 System Feature 1
1.2 Document Conventions 3.2 System Feature 2 (and so on)
1.3 Intended Audience and Reading 4. External Interface Requirements
Suggestions
4.1 User Interfaces
1.4 Project Scope
4.2 Hardware Interfaces
1.5 References
4.3 Software Interfaces
2. Overall Description 4.4 Communications Interfaces
2.1 Product Perspective
5. Other Non-functional Requirements
2.2 Product Features
5.1 Performance Requirements
2.3 User Classes and Characteristics
5.2 Safety Requirements
2.4 Operating Environment
5.3 Security Requirements
2.5 Design and Implementation Constraints
5.4 Software Quality Attributes
2.6 User Documentation
2.7 Assumptions and Dependencies 6. Other Requirements
Appendix A: Glossary | Appendix B: Analysis Models | Appendix C: Issues
List 20
Thank
You