Software Engineering (2115111)
Module – 2
Software Requirements Analysis and Modelling
Prof: Nilambari G. Narkar
Computer Engineering Department
Requirement Engineering
• The broad spectrum of tasks and techniques that lead to an
understanding of requirements is called requirements
engineering.
• It encompasses seven distinct tasks:
– Inception (Getting Started)
– Elicitation (Gathering Requirements)
– Elaboration (Expanding and Modeling)
– Negotiation (Finding Compromise)
– Specification (Documenting Everything)
– Validation (Quality Assurance)
– Management (Controlling Change)
REQUIREMENTS ELICITING
• Requirements elicitation (requirements gathering).
• It combines elements of problem solving,
elaboration, negotiation, and specification.
• In order to encourage a collaborative, team-
oriented approach to requirements gathering,
stakeholders work together to identify the
problem.
Collaborative Requirements
Gathering
• Basic Guidelines:
– Meetings are conducted and attended by both
software engineers and other stakeholders.
– Rules for preparation and participation are
established.
– An agenda is suggested that is formal enough to cover
all important points but informal enough to encourage
the free flow of ideas.
– A “facilitator” (can be a customer, a developer, or an
outsider) controls the meeting.
– A “definition mechanism” (can be work sheets, flip
charts, or wall stickers or an electronic bulletin board,
chat room, or virtual forum) is used.
Collaborative Requirements
Gathering
• The goal is to identify the problem, propose elements of the
solution, negotiate different approaches, and specify a preliminary
set of solution requirements in an atmosphere that is conducive to
the accomplishment of the goal.
Collaborative Requirements
Gathering
• The sequence of events that lead up to the requirements gathering
meeting, occur during the meeting and follow the meeting:
– Inception: basic questions and answers establish the scope of the problem and
the overall perception of a solution. Out of these initial meetings, the
developer and customers write a one- or two-page “product request.”
– A meeting place, time, and date are selected; a facilitator is chosen; and
attendees from the software team and other stakeholder organizations are
invited to participate. The product request is distributed to all attendees before
the meeting date.
– While reviewing the product request in the days before the meeting, each
attendee is asked to make a list of objects that are part of the environment that
surrounds the system, other objects that are to be produced by the system, and
objects that are used by the system to perform its functions.
– In addition, each attendee is asked to make another list of services (processes
or functions) that manipulate or interact with the objects.
– Finally, lists of constraints (e.g., cost, size, business rules) and performance
criteria (e.g., speed, accuracy) are also developed.
– The lists of objects are displayed in meeting room.
– After individual lists are presented in one topic area, the group creates a
combined list by eliminating redundant entries, adding any new ideas that
come up during the discussion but not deleting anything.
Quality Function Deployment
• Is a quality management technique that translates
the needs of the customer into technical
requirements for software.
• QFD identifies three types of requirements:
– Normal requirements
– Expected requirements
– Exciting requirements
Usage Scenarios
• use cases: provide a description of how the
system will be used.
Elicitation Work Products
• The work products produced as a consequence of requirements
elicitation will vary depending on the size of the system or
product to be built.
• For most systems, the work products include:
– A statement of need and feasibility.
– A bounded statement of scope for the system or product.
– A list of customers, users, and other stakeholders who participated in
requirements elicitation.
– A description of the system’s technical environment.
– A list of requirements (preferably organized by function) and the
domain constraints that apply to each.
– A set of usage scenarios that provide insight into the use of the
system or product under different operating conditions.
– Any prototypes developed to better define requirements.
Each of these work products is reviewed by all people who have
participated in requirements elicitation.
Software Requirements Specification
(SRS)
Table of Contents
Revision History
1. Introduction
1.1 Purpose
1.2 Document Conventions
1.3 Intended Audience and Reading Suggestions
1.4 Project Scope
1.5 References
2. Overall Description
2.1 Product Perspective
2.2 Product Features
2.3 User Classes and Characteristics
2.4 Operating Environment
2.5 Design and Implementation Constraints
2.6 User Documentation
2.7 Assumptions and Dependencies
Software Requirements Specification
(SRS) (Cond…)
3. System Features
3.1 System Feature 1
3.2 System Feature 2 (and so on)
4. External Interface Requirements
4.1 User Interfaces
4.2 Hardware Interfaces
4.3 Software Interfaces
4.4 Communications Interfaces
5. Other Nonfunctional Requirements
5.1 Performance Requirements
5.2 Safety Requirements
5.3 Security Requirements
5.4 Software Quality Attributes
6. Other Requirements
Appendix A: Glossary
Appendix B: Analysis Models
Appendix C: Issues List
DEVELOPING USE CASES
• How an end user interacts with the system under a
specific set of circumstances.
• Actor:
– Primary actors interact to achieve required system
function and derive the intended benefit from the
system. They work directly and frequently with the
software.
– Secondary actors support the system so that primary
actors can do their work.
DEVELOPING USE CASES
• Once actors have been identified, use cases can be developed.
• Following number of questions should be answered by a use
case:
– Who is the primary actor, the secondary actor(s)?
– What are the actor’s goals?
– What preconditions should exist before the story begins?
– What main tasks or functions are performed by the actor?
– What exceptions might be considered as the story is described?
– What variations in the actor’s interaction are possible?
– What system information will the actor acquire, produce, or
change?
– Will the actor have to inform the system about changes in the
external environment?
– What information does the actor desire from the system?
– Does the actor wish to be informed about unexpected changes?
Use Case Diagram Notations
• Use Case:
A use case represents a user goal that can be achieved by accessing the system or
software application. A use case is the specification of a set of actions performed by a
system.
• Association:
Actor and use case can be associated to indicate that the actor participates in that use
case. Therefore, an association correspond to a sequence of actions between
the actor and use case in achieving the use case.
• Actor:
Actors are the entities that interact with a system. Although in most cases,
actors are used to represent the users of system, actors can actually be
anything that needs to exchange information with the system. So,
an actor may be people, computer hardware, other systems, etc.
Use Case Diagram Notations (Contd…)
• System:
The scope of a system can be represented by a system (shape), or
sometimes known as a system boundary. The use cases of the system are
placed inside the system shape, while the actor who interact with the
system are put outside the system.
• Include:
An include relationship specifies how the behavior for the inclusion use case is
inserted into the behavior defined for the base use case.
Use Case Diagram Notations (Contd…)
• Extend:
An extend relationship specifies how the behavior of the extension use case can be
inserted into the behavior defined for the base use case.
• Dependency:
A dependency relationship represents that a model element relies on another
model element for specification and/or implementation.
• Generalization:
A generalization relationship is used to represent inheritance relationship
between model elements of same type.
Website
Use Case Diagram of Student
Management System.
Railway Reservation
Admin
Use Case Diagram of
Railway Reservation
System.
Activity diagram is another important behavioral diagram in UML diagram to describe
dynamic aspects of the system. Activity diagram is essentially an advanced version of flow
chart that modeling the flow from one activity to another activity.
Activity Diagram of ATM.
Activity Diagram of Overall ATM Machine.