Software Engineering (3150711)
Unit-4
Requirement
Analysis & Specification
Dr. Pradyumansinh U. Jadeja
Computer Engineering Department
Darshan Institute of Engineering & Technology, Rajkot
[email protected] +91-9879461848
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.”
"Fred" Brooks Jr. is an American Capers Jones is an
computer architect, software engineer, American specialist in
and computer scientist, best known for software engineering
managing the development of IBM's
methodologies
System/360 family of computers
Prof. Pradyumansinh U. Jadeja #3150711 (SE) Unit 4 – Requirement Analysis & Specification 2
Requirement Engineering
It provides the appropriate mechanism for Requirements fall into two types
understanding Functional requirements Non-Functional requirements
What customer wants
Non- Functional
Analyzing needs Assessing feasibility Functional requirement
requirements s
Negotiating a reasonable solution
Specifying solution unambiguously
Validating the specification
Managing requirements
Don't put what you want to do - before how you need to do
#3150711 (SE) Unit 1 – Introduction to Software & Software
Prof. Pradyumansinh U. Jadeja it 3
Functional requirements Non-functional requirements
Any requirement which specifies what the system Any requirement which specifies how the
Should do. system performs a certain function.
A functional requirement will describe a
A non-functional requirement will
particular behaviour of function of the system
describe how a system should behave
when certain conditions are met, for example:
and what limits there are on its
“Send email when a new customer signs up” or
“Open a new account”.
functionality.
Typical functional requirements Typical non-functional requirements
Business Rules Administrative functions Historical Data Response time Availability Regulatory
Throughput Reliability Manageability
Transaction corrections, Legal or Regulatory
adjustments and cancellations Requirements Utilization Recoverabilit Environmental
y
External Reporting Requirements Authenticatio Static Maintainability Data Integrity
Interfaces n volumetric
Authorization levels Scalability Serviceability Usability
Audit Tracking Capacity Security Interoperabilit
#3150711 (SE) Unit 1 – Introduction to Software & Software y
Prof. Pradyumansinh U. Jadeja 4
Library Management System
Function Requirements Non-function Requirements
Add Article: New entries must be entered in database Safety Requirements: The database may get
Update Article: Any changes in articles should be crashed at any certain time due to virus or
updated in case of update operating system failure. So, it is required to
take the database backup.
Delete Article: Wrong entry must be removed from
Security Requirements: We are going to
system
develop a secured database for the university.
Inquiry Members: Inquiry all current enrolled members There are different categories of users namely
to view their details teaching staff, administrator, library
Inquiry Issuance: Inquiry all database articles staff ,students etc., Depending upon the
category of user the access rights are decided.
Check out Article: To issue any article must be checked
Software Constraints: The development of the
out
system will be constrained by the availability of
Check In article: After receiving any article system will required software such as database and
reenter article by Checking development tools. The availability of these
Inquiry waiting for approvals: Librarian will generates tools will be governed by
all newly application which is in waiting list
Reserve Article: This use case is used to reserve any
bookProf.
with the name of librarian, it can#3150711
Pradyumansinh U. Jadeja
be pledged
(SE) Unit 4 – Requirement Analysis & Specification 5
Requirements Engineering Tasks
1 Inception 2 Elicitation (Requirement 3 Elaboration
Gathering)
Roughly define scope Define requirements Further define requirements
A basic understanding The practice of collecting the Expand and refine
of a problem, people requirements of a system from requirements obtained from
who want a solution, users, customers and other inception & elicitation
the nature of solution stakeholders
Creation of User scenarios,
desired
extract analysis class and
business domain entities
#3150711 (SE) Unit 1 – Introduction to Software & Software
Prof. Pradyumansinh U. Jadeja 6
Requirements Engineering Tasks Cont.
4 Negotiation 5 Specification
Reconcile conflicts Create analysis model
Agree on a deliverable It may be written document, set of graphical models, formal
system that is realistic for mathematical model, collection of user scenarios, prototype or
developers and customers collection of these
SRS (Software Requirement Specification) is a document
that is created when a detailed description of all aspects of
software to build must be specified before starting of project
#3150711 (SE) Unit 1 – Introduction to Software & Software
Prof. Pradyumansinh U. Jadeja 7
Requirements Engineering Tasks Cont.
6 Validation 7 Requirements Management
Ensure quality of requirements It is a set of activities to identify, control &
trace requirements & changes to
Review the requirements specification for requirements (Umbrella Activities) at any
errors, ambiguities, omissions (absence) and time as the project proceeds.
conflicts
#3150711 (SE) Unit 1 – Introduction to Software & Software
Prof. Pradyumansinh U. Jadeja 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?
Prof. Pradyumansinh U. Jadeja #3150711 (SE) Unit 4 – Requirement Analysis & Specification 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
Prof. Pradyumansinh U. Jadeja #3150711 (SE) Unit 4 – Requirement Analysis & Specification 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
Prof. Pradyumansinh U. Jadeja #3150711 (SE) Unit 4 – Requirement Analysis & Specification 11
The requirement analysis model
Describe what the customer wants built
Purpose
System
Establish the foundation for the software design Information
System Function
Provide a set of validation requirements
System Behaviors
Prof. Pradyumansinh U. Jadeja #3150711 (SE) Unit 4 – Requirement Analysis & Specification 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 provides value to all Models e.g.
DFDs
stakeholders e.g.
Data models
State diagrams
Sequence diagrams
Prof. Pradyumansinh U. Jadeja #3150711 (SE) Unit 4 – Requirement Analysis & Specification 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
Prof. Pradyumansinh U. Jadeja #3150711 (SE) Unit 4 – Requirement Analysis & Specification 14
Analysis Modeling Approaches
Structured Analysis Object Oriented Analysis
• Models data elements • Models analysis classes
⁻ Attributes ⁻ Data
⁻ Relationships ⁻ Processes
• Models processes that • Models class
transform data collaborations
Techniques from both approaches are typically used in practice.
Prof. Pradyumansinh U. Jadeja #3150711 (SE) Unit 4 – Requirement Analysis & Specification 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 is also helping the clients to understand their own needs.
SRS
Contains
A complete information description A detailed functional description
A representation of system behaviour
An indication of performance requirements and design constraints
Appropriate validation criteria
Other information suitable to requirements
Prof. Pradyumansinh U. Jadeja #3150711 (SE) Unit 4 – Requirement Analysis & Specification 16
Characteristics of a Good SRS
SRS should be accurate, complete, efficient, and of high quality, so that it does not affect
the entire project plan.
An SRS is said to be of high quality when the developer and user easily understand the
prepared document.
Characteristics of a Good SRS:
Correct Unambiguou Complete
s
SRS is correct when all user SRS is unambiguous SRS is complete when the
requirements are stated in the when every stated requirements clearly define
requirements document. requirement has only what the software is
one interpretation. required to do.
Note that there is no specified
tool or procedure to assure the
correctness of SRS.
Prof. Pradyumansinh U. Jadeja #3150711 (SE) Unit 4 – Requirement Analysis & Specification 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.
Traceable Verifiable Consistent
SRS is traceable when the SRS is verifiable when the SRS is consistent when the
source of each requirement is specified requirements can be subsets of individual
clear and facilitates the verified with a cost-effective requirements defined do
reference of each requirement process to check whether the not conflict with each other.
in future. final software meets those
requirements.
Prof. Pradyumansinh U. Jadeja #3150711 (SE) Unit 4 – Requirement Analysis & Specification 18
Problems Without SRS
Without developing the SRS document, the system would not be properly implemented
according to customer needs.
Software developers would not know whether what they are developing is what exactly is
required by the customer.
Without SRS, it will be very difficult for the maintenance engineers to understand the
functionality of the system.
It will be very difficult for user document writers to write the users’ manuals properly without
understanding the SRS.
Prof. Pradyumansinh U. Jadeja #3150711 (SE) Unit 4 – Requirement Analysis & Specification 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 Nonfunctional 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
Prof. Pradyumansinh U. Jadeja List
#3150711 (SE) Unit 4 – Requirement Analysis & Specification 20
Software Engineering (3150711)
Thank
You
Dr. Pradyumansinh U. Jadeja
Computer Engineering Department
Darshan Institute of Engineering & Technology, Rajkot
[email protected] 91-9879461848
