Software engineering and requirement analysis.pptx

Chapter 2
Requirement Analysis and Modelling

Introduction
Requirements elicitation is the process of gathering and defining the requirements for a
software system. The goal of requirements elicitation is to ensure that the software
development process is based on a clear and comprehensive understanding of the
customer needs and requirements. Requirements elicitation involves the identification,
collection, analysis, and refinement of the requirements for a software system.
It is a critical part of the software development life cycle and is typically performed at the
beginning of the project. Requirements elicitation involves stakeholders from different
areas of the organization, including business owners, end-users, and technical experts.
The output of the requirements elicitation process is a set of clear, concise, and well-
defined requirements that serve as the basis for the design and development of the
software system.

Requirements elicitation is perhaps the most difficult, most error-prone and most
communication intensive software development. It can be successful only through an
effective customer-developer partnership. It is needed to know what the users really
need.
Requirements elicitation Activities:
Requirements elicitation includes the subsequent activities. Few of them are listed below
–
● Knowledge of the overall area where the systems is applied.
● The details of the precise customer problem where the system are going to be
applied must be understood.
● Interaction of system with external requirements.
● Detailed investigation of user needs.
● Define the constraints for system development.

Requirements elicitation Methods:
There are a number of requirements elicitation methods. Few of them are listed below –
1. Interviews
2. Brainstorming Sessions
3. Facilitated Application Specification Technique (FAST)
4. Quality Function Deployment (QFD)
5. Use Case Approach
The success of an elicitation technique used depends on the maturity of the analyst,
developers, users, and the customer involved.

1. Interviews:
Objective of conducting an interview is to understand the customer’s expectations
from the software.
It is impossible to interview every stakeholder hence representatives from groups
are selected based on their expertise and credibility.
Interviews maybe be open-ended or structured.
2. In open-ended interviews there is no pre-set agenda. Context free questions
may be asked to understand the problem.
3. In structured interview, agenda of fairly open questions is prepared. Sometimes
a proper questionnaire is designed for the interview.

2. Brainstorming Sessions:
● It is a group technique
● It is intended to generate lots of new ideas hence providing a platform to share
views
● A highly trained facilitator is required to handle group bias and group conflicts.
● Every idea is documented so that everyone can see it.
● Finally, a document is prepared which consists of the list of requirements and
their priority if possible.

3. Facilitated Application Specification Technique:
It’s objective is to bridge the expectation gap – difference between what the developers think they are
supposed to build and what customers think they are going to get.
A team oriented approach is developed for requirements gathering.
Each attendee is asked to make a list of objects that are-
1. Part of the environment that surrounds the system
2. Produced by the system
3. Used by the system
Each participant prepares his/her list, different lists are then combined, redundant entries are
eliminated, team is divided into smaller sub-teams to develop mini-specifications and finally a draft of
specifications is written down using all the inputs from the meeting.

4. Quality Function Deployment:
In this technique customer satisfaction is of prime concern, hence it emphasizes on the requirements
which are valuable to the customer.
3 types of requirements are identified –
● Normal requirements –
In this the objective and goals of the proposed software are discussed with the customer.
Example – normal requirements for a result management system may be entry of marks,
calculation of results, etc
● Expected requirements –
These requirements are so obvious that the customer need not explicitly state them.
Example – protection from unauthorized access.
● Exciting requirements –
It includes features that are beyond customer’s expectations and prove to be very satisfying
when present. Example – when unauthorized access is detected, it should backup and
shutdown all processes.

The major steps involved in this procedure are –
1. Identify all the stakeholders, eg. Users, developers, customers etc
2. List out all requirements from customer.
3. A value indicating degree of importance is assigned to each requirement.
4. In the end the final list of requirements is categorized as –
● It is possible to achieve
● It should be deferred and the reason for it
● It is impossible to achieve and should be dropped off

4. Use Case Approach:
This technique combines text and pictures to provide a better understanding of the
requirements.
The use cases describe the ‘what’, of a system and not ‘how’. Hence, they only give a
functional view of the system.
The components of the use case design includes three major things – Actor, Use cases, use
case diagram.
1. Actor –
It is the external agent that lies outside the system but interacts with it in some way.
An actor maybe a person, machine etc. It is represented as a stick figure. Actors can
be primary actors or secondary actors.
● Primary actors – It requires assistance from the system to achieve a goal.
● Secondary actor – It is an actor from which the system needs assistance.

2. Use cases –
They describe the sequence of interactions between actors and the system. They
capture who(actors) do what(interaction) with the system. A complete set of use cases
specifies all possible ways to use the system.
3. Use case diagram –
A use case diagram graphically represents what happens when an actor interacts with
a system. It captures the functional aspect of the system.
● A stick figure is used to represent an actor.
● An oval is used to represent a use case.
● A line is used to represent a relationship between an actor and a use
case.

Software Requirement Specification (SRS)
The production of the requirements stage of the software development process is
Software Requirements Specifications (SRS) (also called a requirements document).
This report lays a foundation for software engineering activities and is constructing when
entire requirements are elicited and analyzed. SRS is a formal report, which acts as a
representation of software that enables the customers to review whether it (SRS) is
according to their requirements. Also, it comprises user requirements for a system as well
as detailed specifications of the system requirements.
The SRS is a specification for a specific software product, program, or set of applications
that perform particular functions in a specific environment. It serves several goals
depending on who is writing it. First, the SRS could be written by the client of a system.
Second, the SRS could be written by a developer of the system. The two methods create
entirely various situations and establish different purposes for the document altogether.
The first case, SRS, is used to define the needs and expectation of the users. The second
case, SRS, is written for various purposes and serves as a contract document between

Quality characteristics of a good Software Requirements Specification (SRS)
Quality characteristics of a good Software Requirements Specification (SRS) document
include:
● Complete: The SRS should include all the requirements for the software system, including
both functional and non-functional requirements.
● Consistent: The SRS should be consistent in its use of terminology and formatting, and
should be free of contradictions.
● Unambiguous: The SRS should be clear and specific, and should avoid using vague or
imprecise language.
● Traceable: The SRS should be traceable to other documents and artifacts, such as use cases
and user stories, to ensure that all requirements are being met.
● Verifiable: The SRS should be verifiable, which means that the requirements can be tested
and validated to ensure that they are being met.

● Modifiable: The SRS should be modifiable, so that it can be updated and changed as
the software development process progresses.
● Prioritized: The SRS should prioritize requirements, so that the most important
requirements are addressed first.
● Testable: The SRS should be written in a way that allows the requirements to be
tested and validated.
● High-level and low-level: The SRS should provide both high-level requirements (such
as overall system objectives) and low-level requirements (such as detailed functional
requirements).

● Relevant: The SRS should be relevant to the software system that is being developed, and
should not include unnecessary or irrelevant information.
● Human-readable: The SRS should be written in a way that is easy for non-technical
stakeholders to understand and review.
● Aligned with business goals: The SRS should be aligned with the overall business goals and
objectives of the organization, so that the software system meets the needs of the business.
● Agile methodologies: Agile methodologies, such as Scrum and Kanban, provide an iterative
approach to requirements capturing and validation, where requirements are captured and
validated in small chunks of functionality and feedback is gathered from the customer.
By keeping these quality characteristics in mind, developers and stakeholders can ensure that the SRS
document is clear, complete, and accurate, which in turn can help to ensure that the final software
system meets the needs of the business and its users.

Software Requirement Specification (SRS) Format
points which can be used and should be considered to form a structure of good SRS.
These are as follows : 1. Introduction
● (i) Purpose of this document
● (ii) Scope of this document
● (iii) Overview
2. General description
3. Functional Requirements
4. Interface Requirements
5. Performance Requirements
6. Design Constraints
. Non-Functional Attributes
8. Preliminary Schedule and Budget
9. Appendices

1. Introduction :
● (i) Purpose of this Document – At first, main aim of why this document is
necessary and what’s purpose of document is explained and described.
● (ii) Scope of this document – In this, overall working and main objective
of document and what value it will provide to customer is described and
explained. It also includes a description of development cost and time
required.
● (iii) Overview – In this, description of product is explained. It’s simply
summary or overall review of product.
2. General description : In this, general functions of product which includes
objective of user, a user characteristic, features, benefits, about why its
importance is mentioned. It also describes features of user community.

3. Functional Requirements : In this, possible outcome of software system which includes
effects due to operation of program is fully explained. All functional requirements which may
include calculations, data processing, etc. are placed in a ranked order.
4. Interface Requirements : In this, software interfaces which mean how software program
communicates with each other or users either in form of any language, code, or message
are fully described and explained. Examples can be shared memory, data streams, etc.
5. Performance Requirements : In this, how a software system performs desired functions
under specific condition is explained. It also explains required time, required memory,
maximum error rate, etc.
6. Design Constraints : In this, constraints which simply means limitation or restriction are
specified and explained for design team. Examples may include use of a particular algorithm,
hardware and software limitations, etc.

7. Non-Functional Attributes : In this, non-functional attributes are explained
that are required by software system for better performance. An example
may include Security, Portability, Reliability, Reusability, Application
compatibility, Data integrity, Scalability capacity, etc.
8. Preliminary Schedule and Budget : In this, initial version and budget of
project plan are explained which include overall time duration required and
overall cost required for development of project.
9. Appendices : In this, additional information like references from where
information is gathered, definitions of some specific terms, acronyms,
abbreviations, etc. are given and explained.

Use case
In software and systems engineering, a use case is a list of actions or event steps,
typically defining the interactions between a role (known in the Unified Modeling
Language as an actor) and a system, to achieve a goal. The actor can be a human,
an external system, or time. In systems engineering, use cases are used at a higher
level than within software engineering, often representing missions or stakeholder
goals. Another way to look at it is a use case describes a way in which a real-world
actor interacts with the system. In a system use case you include high-level
implementation decisions. System use cases can be written in both an informal
manner and a formal manner. (Wiki)

What is the importance of Use Cases?
Use cases have been used extensively over the past few decades. The advantages of
Use cases includes:
● The list of goal names provides the shortest summary of what the system will
offer
● It gives an overview of the roles of each and every component in the system. It
will help us in defining the role of users, administrators etc.
● It helps us in extensively defining the user’s need and exploring it as to how it
will work.
● It provides solutions and answers to many questions that might pop up if we
start a project unplanned.

How to plan use case?
Use Case: What is the main objective of this use case. For eg. Adding a software
component, adding certain functionality etc.
Primary Actor: Who will have the access to this use case. In the above examples,
administrators will have the access.
Scope: Scope of the use case
Level: At what level the implementation of the use case be.
Flow: What will be the flow of the functionality that needs to be there. More
precisely, the work flow of the use case.

Generally, the use-cases diagram is used for:
○ Examining the system's requirements.
○ Capturing the system's Functionalities.
○ We use use-case diagram in order to modeling the general idea behind the
system.
○ System's Forward and reverse engineering using several test cases.
○ Complex visual designing of software.

Basic Use-Case Diagram Symbols and Notations
There are following use-case diagram symbols and notations:
System
With the help of the rectangle, we can draw the boundaries of the system, which includes use-cases. We
need to put the actors outside the system's boundaries.

Use-Case
With the help of the Ovals, we can draw the use-cases. With the verb we have to
label the ovals in order to represent the functions of the system.

Actors
Actors mean the system's users. If one system is the actor of the other system, then with the actor
stereotype, we have to tag the actor system.

To write a use case, follow the steps given below:
1. Identify the system’s actors and start with one of the actors, for example, the
customer of an e-commerce website.
2. Define what the customer wants to use the system for. For example,
browsing information or online shopping. All these actions will become the
use cases.
3. For each use case, describe the normal and alternate flow of events. The flow
of events should include the customer’s actions and the system’s responses
to them.
Repeat the steps for all the actors of the system.

Use Case ID 1
Use Case Name View Orders
Actors Admin
Description The admin will be able to view all the orders placed by
the customer.
Normal Flow The admin will log in.
The admin will select the 'View Orders' option.
The admin will be prompted to select any filters (date
or time).
The admin will select the filters.
The system will display the relevant orders on the
screen.
Alternate Flow None

Requirements Modeling
Requirements modeling is comparable to the planning stage of a project, where a
software program must be updated or created from scratch. Learn how to identify the
requirements, and the patterns, functions, classes, and behaviors.
Requirements modeling in software engineering is essentially the planning stage of a
software application or system. Generally, the process will begin when a business or an
entity (for example, an educational institution) approaches a software development team
to create an application or system from scratch or update an existing one. Requirements
modeling comprises several stages, or 'patterns': scenario-based modeling, data
modeling, flow-oriented modeling, class-based modeling and behavioral modeling. Each
of these stages/patterns examines the same problem from a different perspective.

Identifying Requirements
Requirements in this context are the conditions that a proposed solution or
application must meet in order to solve the business problem. Identifying
requirements is not an exclusively technical process, and initially involves all the
stakeholders, like the representatives of the entity that has commissioned the
software project, who may not necessarily be from a technical background, as
well as the software developers, who are not necessarily the technical team.
Together, they discuss and brainstorm about the problem, and decide what
functions the proposed application or system must perform in order to solve it.

Identifying Requirements
Functional vs. Non-Functional Requirements
A functional requirement specifies something that the application or system should do.
Often, this is defined as a behavior of the system that takes input and provides output. For
example, a traveler fills out a form in an airline's mobile application with his/her name and
passport details (input), submits the form, and the application generates a boarding pass with
the traveler's details (output).
Non-functional requirements, sometimes also called quality requirements, describe how
the system should be, as opposed to what it should do. Non-functional requirements of a system
include performance (e.g., response time), maintainability and scalability, among many others.
In the airline application example, the requirement that the application must display the
boarding pass after a maximum of five seconds from the time the traveler presses the 'submit'
button would be a non-functional requirement.

Working with Requirements Modeling
Requirements modeling includes several stages, or patterns, each examining the
problem and its proposed solution from a different perspective. Technically,
there is no 'right way' of going through these stages, but generally, the process
would begin with scenario-based modeling and complete with behavioral
modeling.

Scenario-based Modeling
Scenario-based modeling's primary objective is to look at a system from the user's perspective and
produce a use case, an example instance of the user interacting with the system, like the traveler using the
airline application to generate their boarding pass. It makes sense to start with this step as the other
requirements modeling stages/patterns will make reference to this use case.
Below is a use case diagram depicting three possible use cases of the traveler using the airline
application. The first is the one in the example, getting a boarding pass. The following two are searching
for flights and buying air tickets.

Class-based Modeling
Class-based modeling identifies classes, attributes and relationships that the system will use.
In the airline application example, the traveler/user and the boarding pass represent classes.
The traveler's first and last name and travel document type represent attributes,
characteristics that describe the traveler class. The relationship between traveler and
boarding pass classes is that the traveler must enter these details into the application in
order to get the boarding pass and that the boarding pass contains this information along
with other details, like the flight departure gate, seat number, etc.
Data Modeling
Data modeling essentially works with the same elements as class-based modeling (object,
attributes, relationships), but uses the information to produce a detailed model, termed a
physical model, of what the database structure will be that will hold all the data; for example,
the name, passport number and other details of the travelers that use the airline application.

Behavioral Model :
Effect of behavior of computer-based system can be seen on design that is chosen
and implementation approach that is applied. Modeling elements that depict
behavior must be provided by requirements model.
Method for representing behavior of a system by depicting its states and events
that cause system to change state is state diagram. A state is an externally
observable mode of behavior. In addition, state diagram indicates actions taken
as a consequence of a particular event.

Flow-oriented elements
As it flows through a computer-based system information is transformed. System
accepts input, applies functions to transform it, and produces output in a various
forms. Input may be a control signal transmitted by a transducer, a series of
numbers typed by human operator, a packet of information transmitted on a
network link, or a voluminous data file retrieved from secondary storage.
Transform may compromise a single logical comparison, a complex numerical
algorithm, or a rule-inference approach of an expert system. Output produce a
200-page report or may light a single LED. In effect, we can create a flow model
for any computer-based system, regardless of size and complexity.

Software engineering and requirement analysis.pptx

More Related Content

Similar to Software engineering and requirement analysis.pptx

Recently uploaded

Software engineering and requirement analysis.pptx