Module 2

Requirement Analysis:
Software Requirements: Functional & non-functional – user-system requirement engineering
process – feasibility studies – elicitation – validation & management – software prototyping – S/W
documentation – Analysis and modelling Requirement Elicitation, Software requirement
specification (SRS),

Self-learning Topics: prioritizing requirements (Kano diagram) - real life application case study.

Software Requirement
● In the software development process, requirement phase is the first
software engineering activity.
● This phase is a user-dominated phase and translates the ideas or views into
a requirements document. Note that defining and documenting the user
requirements in a concise and unambiguous manner is the first major step
to achieve a high-quality product.
● The requirement phase encompasses a set of tasks, which help to specify
the impact of the software on the organization, customers’ needs, and how
users will interact with the developed software.
● The requirements are the basis of the system design. If requirements are
not correct the end product will also contain errors.
Software Requirements: Functional & non-
functional
● The end goal of a project is to deliver a high quality product exactly as
the customer asked for.

● Functional requirements are the primary way that a customer

communicates their requirements to the project team. Functional
requirements help to keep project team going in the right direction.

● Unclear requirements leads to a poorly defined scope that creates a lot of

challenges from the beginning of the project.
 ● A poorly defined scope leads to extension in the schedule and increase in
cost. The customer may not have the time and money to invest, so they
just accept a product with low quality.
● Understanding the difference between functional and non-functional requirements
will help both, the client and the IT supplier as they will be able to understand their
requirements clearly.

● This leads to scope refinement, optimized cost, and finally a happy customer.

What are Functional Requirements?

● The definition of a functional requirement is:

“Any Requirement Which Specifies What The System Should Do.”

● In other words, a functional requirement will describe a particular behavior
of function of the system when certain conditions are met, for example:
“Send email when a new customer signs up” or “Open a new account”.

Some of the more typical functional requirements include:

● Business Rules

● Transaction corrections, adjustments and cancellations

● Administrative functions

● Authentication

● Authorization levels

● Audit Tracking

● External Interfaces

● Certification Requirements

● Reporting Requirements
 ● Historical Data

● Legal or Regulatory Requirements.

What are non-functional requirements?

The definition of a non-functional requirement is:

● “Any Requirement That Specifies How The System Performs A Certain

Function.”

● In other words, a non-functional requirement will describe how a system

should behave and what limits there are on its functionality.

● Non-functional requirements cover all the remaining requirements which

are not covered by the functional requirements.

● They specify criteria that judge the operation of a system, rather than
specific behaviours, for example: “Modified data in a database should be
updated for all users accessing it within 2 seconds
● Non-functional requirements when defined and executed well will help to
make the system easy to use and enhance the performance.

● Non-functional requirements focus on user expectations, as they are

product properties.
●take an example of a non nfunctional requirement. A system loads a
webpage when someone clicks on a button. The related non-functional
requirement specifies how fast the webpage must load. A delay in loading
will create a negative user experience and poor quality of the system even
though the functional requirement is fully met.
● Some typical non-functional requirements are:

● Performance – for example Response Time, Throughput, Utilization,

Static Volumetric
● Scalability

● Capacity

● Availability

● Reliability

● Recoverability

● Maintainability

● Serviceability

● Security

● Regulatory

● Manageability
●

User requirements
● User requirements are statements, in a natural language plus diagrams, of
what services the system is expected to provide to system users and the
constraints under which it must operate.
● The user requirements may vary from broad statements of the system
features required to detailed, precise descriptions of the system
functionality.
●

System requirements
● System requirements are more detailed descriptions of the software
system’s functions, services, and operational constraints.
 ● The system requirements document (sometimes called a functional
specification) should define exactly what is to be implemented. It may be
part of the contract between the system buyer and the software
developers.

Feasibility Study
● Feasibility Study in Software Engineering is a study to evaluate
feasibility of proposed project or system.

● As name suggests feasibility study is the feasibility analysis or it is a

measure of the software product in terms of how much beneficial product
development will be for the organization in a practical point of view.

● Feasibility study is carried out based on many purposes to analyze

whether software product will be right in terms of development,
implantation, contribution of project to the organization etc.

Types of Feasibility Study :

1.Technical Feasibility
2.Operational Feasibility
3.Operational Feasibility –

Technical Feasibility –
● In Technical Feasibility current resources both hardware software along
with required technology are analyzed/assessed to develop project.
● This technical feasibility study gives report whether there exists correct
required resources and technologies which will be used for project
development.
● Along with this, feasibility study also analyzes technical skills and
capabilities of technical team, existing technology can be used or not,
maintenance and up-gradation is easy or not for chosen technology etc.

● Operational Feasibility –
In Operational Feasibility degree of providing service to requirements is
analyzed along with how much easy product will be to operate and
maintenance after deployment.
● Along with this other operational scopes are determining usability of
product, Determining suggested solution by software development team is
acceptable or not etc.

● Economic Feasibility –
In Economic Feasibility study cost and benefit of the project is analyzed.
● Means under this feasibility study a detail analysis is carried out what will
be cost of the project for development which includes all required cost for
final development like hardware and software resource required, design
and development cost and operational cost and so on.

● After that it is analyzed whether project will be beneficial in terms of

finance for organization or not.

Requirements elicitation
● 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 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 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:

Requirements elicitation Methods:
There are a number of requirements elicitation methods. Few of them are listed
below –
● Interviews

● Brainstorming Sessions

● Facilitated Application Specification Technique (FAST)

● Quality Function Deployment (QFD)

● Use Case Approach

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.

● In open-ended interviews there is no pre-set agenda. Context free
questions may be asked to understand the problem.
● 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-

● Part of the environment that surrounds the system

 ● Produced by the system

● Used by the system

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 –

1.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
2.Expected requirements –
● These requirements are so obvious that the customer need not explicitly
state them. Example – protection from unauthorized access.
3.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.
Use Case Approach:
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.

Requirements validation
● Requirements validation is the process of checking that requirements
defined for development, define the system that the customer really
wants.
●
To check issues related to requirements, we perform requirements
validation.
●
use requirements validation to check error at the initial phase of
development as the error may increase excessive rework when detected
later in the development process.
● In the requirements validation process, we perform a different type of test
to check the requirements mentioned in the Software Requirements
Specification (SRS), these checks include:

● Completeness checks

● Consistency checks

● Validity checks

● Realism checks

● Ambiguity checks

● Verifiability.
● he output of requirements validation is the list of problems and agreed on
actions of detected problems.

● The lists of problems indicate the problem detected during the process of
requirement validation. The list of agreed action states the corrective
action that should be taken to fix the detected problem.

● There are several techniques which are used either individually or in

conjunction with other techniques to check to check entire or part of the
system:
1.Test case generation:
● Requirement mentioned in SRS document should be testable, the
conducted tests reveal the error present in the requirement. It is generally
believed that if the test is difficult or impossible to design than, this
usually means that requirement will be difficult to implement and it should
be reconsidered.
2.Prototyping:
● In this validation techniques the prototype of the system is presented
before the end-user or customer, they experiment with the presented model
and check if it meets their need. This type of model is generally used to
collect feedback about the requirement of the user.

3.Requirements Reviews:
● In this approach, the SRS is carefully reviewed by a group of people
including people from both the contractor organisations and the client side,
the reviewer systematically analyses the document to check error and
ambiguity.

4.Automated Consistency Analysis:

● This approach is used for automatic detection of an error, such as
nondeterminism, missing cases, a type error, and circular definitions, in
requirements specifications.

5.Walk-through:
● A walkthrough does not have a formally defined procedure and does not
require a differentiated role assignment.
● Checking early whether the idea is feasible or not.

● Obtaining the opinions and suggestion of other people.

 ● Checking the approval of others and reaching an agreement.
Requirement management
● The purpose of requirements management is to ensure product
development goals are successfully met.
●
It is a set of techniques for documenting, analyzing, prioritizing, and
agreeing on requirements so that engineering teams always have current
and approved requirements.
●
Requirements management provides a way to avoid errors by keeping
track of changes in requirements and fostering communication with
stakeholders from the start of a project throughout the engineering
lifecycle.

● Requirements management is the process of how companies

define, manage, verify, and validate ideas and meet
stakeholder needs at every step of the product lifecycle
beginning as early as idea creation through product
development and commercialization.
●
The requirements management process typically involves
the following phases:

● Collection: Gathering feedback and needs from customers and internal

teams.
●
Analysis: Determining whether proposed features and requirements align
with the company or product vision.
●
Definition: Documenting requirements from the user perspective and
detailing functional or technical requirements.
 ●
Planning upcoming releases or sprints and the features and requirements
that will be included.
●
Validation and maintenance: Creating a definition of "complete" and
planning ongoing enhancements.

●Software Prototyping
What Is Software Prototyping?

● Software prototyping refers to the process of visualising a software

product before it has been created.
●
Creating software from scratch requires a great investment in the form of
time, money, and effort. That is why most clients prefer to have a visual
prototype developed before work is put into the development of the actual
product.
●
The prototype acts as a ‘model’ closely replicating the appearance, and
sometimes the functionality, of the product that the client has in mind.

●What Are The Different Types Of Prototyping

Models?
1..Throwaway Prototyping
● As its name suggests, a throwaway prototype is ‘thrown out’
once the product design is finalised. Also known as rapid
prototyping, this technique is carried out over a short time.
● The designer can quickly hash out some design ideas in this
phase, somewhat like a rough sketch. Some of the key
functionality may also be incorporated into the software
prototype.

2.Evolutionary Prototyping
 ● The name for this type of software prototyping is also quite self-
explanatory. Starting with the basics, the evolutionary software
prototyping technique allows the product to grow – evolve – over multiple
iterations.

● an evolutionary prototype is a functional piece of software, not just a

simulation. Evolutionary prototyping starts with a product that meets only
the system requirements that are understood.
●
It won’t do everything the customer requires, but it makes a good starting
point. New features and functions can be added as those requirements
become clear to the stakeholders. That’s the “evolutionary” nature of this
prototype.
● The screens (user interface) also have actual code behind them. The user
can see and interact with the prototype as if it were the actual product

● Over time and multiple feedback cycles, the prototype may have more
advanced functionality added to it as needed by the client. The process
thus results in the finished product.

3. Incremental Prototyping
● This may sound similar to evolutionary prototyping but both of them are
miles apart. While evolutionary prototyping focuses on starting from the
basics and building upon the skeletal structure,
●
incremental prototyping is based on breaking down the whole product
into multiple modules and sub-modules, and working on them
individually. Each module has its own prototype which is built upon over
time.
●
All these functional prototypes are then merged to form a single, final
software application.
4. EXTREME PROTOTYPING
Extreme prototyping is more common for web application development. Web
applications are composed of:

1.Presentation layer
 ● Displayed in the user’s browser

2.Services layer
● Communications services

● Business logic

● Authentication and authorization

● Other back-end services

Extreme prototyping is conducted in three phases:

● Build HTML wireframes to simulate the presentation layer. These web

pages have limited interactivity. They are complete enough to show users
the various user journeys through the application.
●
Transform the wireframes to fully functional HTML pages, tying them to
a simulated services layer.
●
Code and implement the services layer.

S/W documentation
What is Software Documentation?
● Software documentation is written material, images, or video instructions
that come with computer software. As a rule, software documentation
explains how to use a program or a service.
●
However, there may be different types of software documentation,
depending on the audience it is created for. Here are some examples of
the software documentation types:

1.Requirements documentation. Typically created in the beginning of a

software development project. Has the goal to clearly and precisely specify
the expectations in regards to the software being created. May include
 functional requirements, limitations, hardware or software requirements,
compatibility requirements, and so on.

2.Architecture documentation. Defines the high-level architecture of the

software system being created. May describe the main components of the
system, their roles and functions, as well as the data and control flow
among those components.

3.Technical documentation - Documentation of the software code,

algorithms, APIs. Written for the technical audience like software
developers.

4.End user documentation.

Creating User
Documentation
● There’s a certain process developed over the years for creating quality
user guides. Some steps can alter, but the skeleton remains the same. The
most common documentation authoring process includes five steps:
●
First, there’s the user analysis. At this stage the basic characteristics of
the users are researched. This is highly important to know for whom the
documentation is written order to tailor it out for them.
●
On this stage, the planning is done and the documents are actually
written.
●
The documentation draft review is performed. Documentation writers
gather feedback on the draft created at the previous step.

● Usability testing. The documentation usability is tested. The QA team can

be included into this step for higher efficiency of help authoring.
●
The final step is editing. All the information that was collected on steps 3
and 4 is analysed in order to produce the final draft.
ANALYSIS and Modeling
● Requirements analysis results in the specification of software’s operational
characteristics,indicates software’s interface with other system elements,
and establishes constraints that software must meet.
● The requirements modeling action results in one or more of the following
types of models:
1.Scenario-based models of requirements from the point of view of various
system “actors”1.Use case diagram2. activity diagram 3.swimpalne diagram.

2. Data models that depict the information domain for the problem.Er-diagram.

3.Class-oriented models that represent object-oriented classes (attributes and

operations) and the manner in which classes collaborate to achieve system
requirement.class diagram.
4.Flow-oriented models that represent the functional elements of the system and
how they transform data as it moves through the system. DFD Diagram

5. Behavioral models that depict how the software behaves as a consequence of

external “events” Sequence diagram.
● These models provide a software designer with information that can be
translated to architectural, interface, and component-level designs.
 ● Finally, the requirements model provides the developer and the customer
with the means to assess quality once software is built.

● Throughout requirements modeling, your primary focus is on what, not

how. The requirements model must achieve three primary objectives:

(1)to describe what the customer requires,

(2) to establish a basis for the creation of a softwaredesign, and
(3) to define a set of requirements that can be validated once the software is
built.

The analysis model bridges the gap between a system-level description that
describes overall system or business functionality as it is achieved by applying
software, hardware, data, human,and other system elements and a software
design.
SCENARIO-BASED MODELING
● Requirements modeling with UML begins with the creation of scenarios
in the form of
1.use cases,
2. activity diagrams
3. swimlane diagrams.
Use Case Diagram
What is a Use Case Diagram?
● A use case diagram is a dynamic or behavior diagram in UML. Use case
diagrams model the functionality of a system using actors and use cases.
●
Use cases are a set of actions, services, and functions that the system
needs to perform. In this context, a "system" is something being
developed or operated, such as a web site. The "actors" are people or
entities operating under defined roles within the system.
● Basic Use Case Diagram Symbols and Notations
1.System
● Draw your system's boundaries using a rectangle that contains use cases.
Place actors outside the system's boundaries.

● The figure shows the system boundary of the clinic application.

● The use cases of this system are enclosed in a rectangle. Note that the
actors in the system are outside the system boundary.
● For large and complex systems, each of the modules may be the system
boundary
2.Use Case
● Draw use cases using ovals. Label the ovals with verbs that represent the
system's functions.

3.Actors
● Actors are the users of a system. When one system is the actor of another
system, label the actor system with the actor stereotype.

4.Relationships
● Illustrate relationships between an actor and a use case with a simple line.
For relationships among use cases, use arrows labeled either "uses" or
"extends." A "uses" relationship indicates that one use case is needed by
another in order to perform a task. An "extends" relationship indicates
alternative options under a certain use case.
Include relationship
● Include relationship is modelled between the use cases when a use case
includes the behavior sequence of another use case.

● The use cases that need to be described repeatedly for a complex or a large
system are modelled once and included in the other uses cases when
required.

● Include use case is similar to subroutines, as they are the set of instructions
which are repeatedly used in the program, but this set of instructions is
written only once and are called whenever required.

Include Relationship Example

● Include use case is similar to subroutines, as they are the set of instructions
which are repeatedly used in the program, but this set of instructions is
written only once and are called whenever required.

● So, the use cases secure session includes the use case ‘validate password’
and similarly make a trade use case also includes validate password use
case. You can observe in the figure above that though use case validate
password is repeatedly used by other use cases and it is modelled only
once.

● The include relationship is presented with a dashed arrow in UML

diagram. The arrow head is pointing towards the included use case.
● Diagram
 Extend relationship
●Example
● Extend relationship adds up behavior sequence to the base use case. It is
somewhat similar to the include relationship but the direction of adding
behaviour sequence to the base use case is opposite.

● For this situation, the stock brokerage system adds a feature or extension,
margin trade which allows the customer to take a loan to purchase the
stock. This additional feature is added to the base use case when
(condition) the stocks purchase cost is checked against the balance
available in the customer account and it is found that the balance is
insufficient to purchase the stock.

● The extend relationship in UML notation is represented with the dashed

arrow. The arrow head points to the base use case. This dashed arrow is
annotated by the keyword <<extend>>.
Diagram
Generalization
● Generalization is the most common term in computers. In generalization,
there is a parent class consisting of common attributes and operations and
the child class contains the refined attributes and operations.

● The parent use case contains the common behavior sequence and the child
use case contains the refined features. Generalization in the use case is
 represented with the triangular arrow where the arrow head points to the
parent use case.

● The child class add up attributes and operation to the parent class but the
order of insertion is not so important.

● While the child use case adds its behavior sequence in a specific location
within the behavior sequence of the parent class.

Diagram
Examples of Use Case
Diagram
● he Document Management System
(DMS) use case diagram example
below shows the actors and use
cases of the system. In particular,
there are include and extend
relationships among use cases.
Activity Diagram
What is an Activity Diagram?
● An activity diagram visually presents a series of actions or flow of control
in a system similar to a flowchart or a data flow diagram. Activity
diagrams are often used in business process modeling.

● They can also describe the steps in a use case diagram. Activities modeled
can be sequential and concurrent. In both cases an activity diagram will
have a beginning (an initial state) and an end (a final state).
● Basic Activity Diagram Notations and Symbols
1.Initial State or Start Point
● A small filled circle followed by an arrow represents the initial action state
or the start point for any activity diagram. For activity diagram using
swimlanes, make sure the start point is placed in the top left corner of the
first column.

2.Activity or Action State

An action state represents the non-interruptible action of objects. You can draw
an action state in SmartDraw using a rectangle with rounded corners.
3.Action Flow
Action flows, also called edges and paths, illustrate the transitions from one
action state to another. They are usually drawn with an arrowed line.

..Object Flow

Object flow refers to the creation and modification of objects by activities. An

object flow arrow from an action to an object means that the action creates or
influences the object. An object flow arrow from an object to an action indicates
that the action state uses the object.

5.Decisions and Branching

 ● A diamond represents a decision with alternate paths. When an activity
requires a decision prior to moving on to the next activity, add a diamond
between the two activities. The outgoing alternates should be labeled with
a condition or guard expression. You can also label one of the paths "else."

6.Guards
● In UML, guards are a statement written next to a decision diamond that
must be true before moving next to the next activity. These are not
essential, but are useful when a specific answer, such as "Yes, three labels
are printed," is needed before moving forward.

7.Synchronization
● A fork node is used to split a single incoming flow into multiple
concurrent flows. It is represented as a straight, slightly thicker line in an
activity diagram.
● A join node joins multiple concurrent flows back into a single outgoing
flow

● A fork and join mode used together are often referred to as

synchronization.
8.Time Event
● This refers to an event that stops the flow for a time; an hourglass depicts
it.

9.Merge Event
● A merge event brings together multiple flows that are not concurrent.
Activity Diagram - Modeling a Word Processor
● Open the word processing package.

● Create a file.

● Save the file under a unique name within its directory.

● Type the document.

● If graphics are necessary, open the graphics package, create the graphics,
and paste the graphics into the document.
● If a spreadsheet is necessary, open the spreadsheet package, create the
spreadsheet, and paste the spreadsheet into the document.
● Save the file.

● Print a hard copy of the document.

● Exit the word processing package.