CPE 310 SOFTWARE ENGINEERING

Spring Semester-2021

Dr. Nesrin AYDIN ATASOY

Week 5: Software Request Analysis

➢ What is Request?

Request: Means that is required, desired or needed.

Request Definition: The requirements of a system are the definition of the services and functional
constraints provided by that system..

IEEE 729: Situation or support needed by the user to solve a problem or achieve a goal.

The requirement is not related to how the system or its functions will be fulfilled. It is about what it is.

• which database,

• which tables,

• how much memory is used,

these are handled during the realization phase.

➢ What is Request Engineering?

All services and restrictions,

• Identify,
• Analyzing,
• Certification
• Checking

The process is called Request Engineering.

➢ Why are request important?

Mistakes arising from requirements are noticed in the late stages. Often wrong information is caused by
negligence and inconsistency. In this case, correction costs will be high.

➢ Change of Request

Although the analysis of the requirements is very good, changes may occur during the process. Fort
his reasons:

• Communication between the customer and the developer is not sufficient,

• Some assumptions or assumptions have been made in order to pass the analysis of the
demands quickly,
 • Customer not knowing exactly what he wants and changing ideas frequently,
• The developer's lack of experience,
• The emergence of the necessity of new requests when we move on to detailed design

It should not be forgotten that no matter how much changes, all requests must be informed of the
customer and must be certified.

➢ Requirements Engineering Process

Requirements analysis, also called requirements engineering, is the process of determining user
expectations for a new or modified product. Requirements engineering is a major software engineering
action that begins during the communication activity and continues into the modeling activity. It must
be adapted to the needs of the process, the project, the product, and the people doing the work.
Requirements engineering builds a bridge to design and construction. It has four step process:

Feasibility Study: When the client approaches the organization for getting the desired product
developed, it comes up with rough idea about what all functions the software must perform and which
all features are expected from the software.

Referencing to this information, the analysts does a detailed study about whether the desired system and
its functionality are feasible to develop.

This feasibility study is focused towards goal of the organization. This study analyzes whether the
software product can be practically materialized in terms of implementation, contribution of project to
organization, cost constraints and as per values and objectives of the organization. It explores technical
aspects of the project and product such as usability, maintainability, productivity and integration ability.

The output of this phase should be a feasibility study report that should contain adequate comments and
recommendations for management about whether or not the project should be undertaken.

Requirement Gathering: If the feasibility report is positive towards undertaking the project, next phase
starts with gathering requirements from the user. Analysts and engineers communicate with the client
and end-users to know their ideas on what the software should provide and which features they want the
software to include.

Software Requirement Specification (SRS): SRS is a document created by system analyst after the
requirements are collected from various stakeholders.

SRS defines how the intended software will interact with hardware, external interfaces, speed of
operation, response time of system, portability of software across various platforms, maintainability,
speed of recovery after crashing, Security, Quality, Limitations etc.
The requirements received from client are written in natural language. It is the responsibility of system
analyst to document the requirements in technical language so that they can be comprehended and useful
by the software development team.

SRS should come up with following features:

• User Requirements are expressed in natural language.

• Technical requirements are expressed in structured language, which is used inside the
organization.
• Design description should be written in Pseudo code.
• Format of Forms and GUI screen prints.
• Conditional and mathematical notations for DFDs etc.

Software Requirement Validation: After requirement specifications are developed, the requirements
mentioned in this document are validated. User might ask for illegal, impractical solution or experts may
interpret the requirements incorrectly. This results in huge increase in cost if not nipped in the bud.
Requirements can be checked against following conditions:

• If they can be practically implemented

• If they are valid and as per functionality and domain of software
• If there are any ambiguities
• If they are complete
• If they can be demonstrated

➢ Requirement Elicitation Process

Requirement elicitation process can be depicted using the folloiwng diagram:

Requirements gathering: The developers discuss with the client and end users and know their
expectations from the software.

Organizing Requirements: The developers prioritize and arrange the requirements in order of
importance, urgency and convenience.

Negotiation & discussion: If requirements are ambiguous or there are some conflicts in requirements
of various stakeholders, if they are, it is then negotiated and discussed with stakeholders. Requirements
may then be prioritized and reasonably compromised.
The requirements come from various stakeholders. To remove the ambiguity and conflicts, they are
discussed for clarity and correctness. Unrealistic requirements are compromised reasonably.

Documentation: All formal & informal, functional and non-functional requirements are documented
and made available for next phase processing.

➢ Requirement Elicitation Techniques

Requirements Elicitation is the process to find out the requirements for an intended software system
by communicating with client, end users, system users and others who have a stake in the software
system development.

There are various ways to discover requirements:

1. Interviews

Interviews are strong medium to collect requirements. Organization may conduct several types of
interviews such as:

• Structured (closed) interviews, where every single information to gather is decided in advance,
they follow pattern and matter of discussion firmly.
• Non-structured (open) interviews, where information to gather is not decided in advance, more
flexible and less biased.
• Oral interviews
• Written interviews
• One-to-one interviews which are held between two persons across the table.
• Group interviews which are held between groups of participants. They help to uncover any
missing requirement as numerous people are involved.

2. Surveys

Organization may conduct surveys among various stakeholders by querying about their expectation and
requirements from the upcoming system.

3. Questionnaires

A document with pre-defined set of objective questions and respective options is handed over to all
stakeholders to answer, which are collected and compiled.
A shortcoming of this technique is, if an option for some issue is not mentioned in the questionnaire, the
issue might be left unattended.

4. Task analysis

Team of engineers and developers may analyze the operation for which the new system is required. If
the client already has some software to perform certain operation, it is studied and requirements of
proposed system are collected.

5. Domain Analysis

Every software falls into some domain category. The expert people in the domain can be a great help
to analyze general and specific requirements.

6. Brainstorming

An informal debate is held among various stakeholders and all their inputs are recorded for further
requirements analysis.

7. Prototyping

Prototyping is building user interface without adding detail functionality for user to interpret the features
of intended software product. It helps giving better idea of requirements. If there is no software installed
at client’s end for developer’s reference and the client is not aware of its own requirements, the developer
creates a prototype based on initially mentioned requirements. The prototype is shown to the client and
the feedback is noted. The client feedback serves as an input for requirement gathering.

8. Observation

Team of experts visit the client’s organization or workplace. They observe the actual working of the
existing installed systems. They observe the workflow at client’s end and how execution problems
are dealt. The team itself draws some conclusions which aid to form requirements expected from the
software.

➢ Software Requirements Characteristics

Gathering software requirements is the foundation of the entire software development project. Hence
they must be clear, correct and well-defined.
A complete Software Requirement Specifications must be:

• Clear
• Correct
• Consistent
• Coherent
 • Comprehensible
• Modifiable
• Verifiable
• Prioritized
• Unambiguous
• Traceable
• Credible source

➢ Software Requirements

We should try to understand what sort of requirements may arise in the requirement elicitation phase
and what kinds of requirements are expected from the software system.

Software requirements should be categorized in two categories:

1. Functional Requirements

Requirements, which are related to functional aspect of software fall into this category. They define
functions and functionality within and from the software system.

Examples:

• Search option given to user to search from various invoices.

• User should be able to mail any report to management.
• Users can be divided into groups and groups can be given separate rights.
• Should comply business rules and administrative functions.
• Software is developed keeping downward compatibility intact.

2. Non-Functional Requirements

Requirements, which are not related to functional aspect of software, fall into this category. They are
implicit or expected characteristics of software, which users make assumption of. Non-functional
requirements include:

• Security
• Logging
• Storage
• Configuration
• Performance
• Cost
• Interoperability
 • Flexibility
• Disaster recovery
• Accessibility

Requirements are categorized logically as:

Must Have: Software cannot be said operational without them.

Should have: Enhancing the functionality of software.

Could have: Software can still properly function with these requirements.

Wish list: These requirements do not map to any objectives of software.

While developing software, ‘Must have’ must be implemented, ‘Should have’ is a matter of debate with
stakeholders and negation, whereas ‘could have’ and ‘wish list’ can be kept for software updates.

➢ User Interface requirements

UI is an important part of any software or hardware or hybrid system. A software is widely accepted if
it is:

• easy to operate
• quick in response
• effectively handling operational errors
• providing simple yet consistent user interface

User acceptance majorly depends upon how user can use the software. UI is the only way for users to
perceive the system. A well performing software system must also be equipped with attractive, clear,
consistent and responsive user interface. Otherwise the functionalities of software system can not be
used in convenient way. A system is said be good if it provides means to use it efficiently. User interface
requirements are briefly mentioned below:

• Content presentation
• Easy Navigation
• Simple interface
• Responsive
• Consistent UI elements
• Feedback mechanism
• Default settings
• Purposeful layout
 • Strategical use of color and texture.
• Provide help information
• User centric approach
• Group based view settings

➢ Software System Analyst

System analyst in an IT organization is a person, who analyzes the requirement of proposed system and
ensures that requirements are conceived and documented properly & correctly. Role of an analyst starts
during Software Analysis Phase of SDLC. It is the responsibility of analyst to make sure that the
developed software meets the requirements of the client.

System Analysts have the following responsibilities:

• Analyzing and understanding requirements of intended software

• Understanding how the project will contribute in the organization objectives
• Identify sources of requirement
• Validation of requirement
• Develop and implement requirement management plan
• Documentation of business, technical, process and product requirements
• Coordination with clients to prioritize requirements and remove and ambiguity
• Finalizing acceptance criteria with client and other stakeholders

➢ Software Metrics and Measures

Software Measures can be understood as a process of quantifying and symbolizing various attributes
and aspects of software. Software Metrics provide measures for various aspects of software process and
software product.

Software measures are fundamental requirement of software engineering. They not only help to control
the software development process but also aid to keep quality of ultimate product excellent.

According to Tom DeMarco, a (Software Engineer), “You cannot control what you cannot measure.”
By his saying, it is very clear how important software measures are.

Let us see some software metrics:

Size Metrics: LOC (Lines of Code), mostly calculated in thousands of delivered source code lines,
denoted as KLOC.
Function Point Count is measure of the functionality provided by the software. Function Point count
defines the size of functional aspect of software.

Complexity Metrics: McCabe’s Cyclomatic complexity quantifies the upper bound of the number of
independent paths in a program, which is perceived as complexity of the program or its modules. It is
represented in terms of graph theory concepts by using control flow graph.

Quality Metrics: Defects, their types and causes, consequence, intensity of severity and their
implications define the quality of product.

The number of defects found in development process and number of defects reported by the client after
the product is installed or delivered at client-end, define quality of product.

Process Metrics: In various phases of SDLC, the methods and tools used, the company standards and
the performance of development are software process metrics.

Resource Metrics: Effort, time and various resources used, represents metrics for resource
measurement.

➢ Requirements Modeling: Scenarios, Information, And Analysis Classes Requirements

Analysis

o Requirements Modeling Approaches

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.
Requirements analysis allows you to elaborate on basic requirements established during the inception,
elicitation, and negotiation tasks that are part of requirements engineering.

The requirements modeling action results in one or more of the following types of models:
 ➢ Scenario-based models of requirements from the point of view of various system

“actors”

➢ Data models that depict the information domain for the problem
➢ Class-oriented models that represent object-oriented classes (attributes and operations)

and the manner in which classes collaborate to achieve system requirements

• Flow-oriented models that represent the functional elements of the system and how they

transform data as it moves through the system

• Behavioral models that depict how the software behaves as a consequence of external

“events”.

The requirements model as a bridge between the system description and the design model:

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 software design, 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 that describes the software’s application architecture, user interface, and
component-level structure.

1. Scenario-Based Modeling

Scenario-based elements depict how the user interacts with the system and the specific sequence of
activities that occur as the software is used.
A use case describes a specific usage scenario in straightforward language from the point of view of a
defined actor. These are the questions that must be answered if use cases are to provide value as a
requirements modeling tool.

(1) what to write about,

(2) how much to write about it,

(3) how detailed to make your description, and (4) how to organize the description?

To begin developing a set of use cases, list the functions or activities performed by a specific actor.

❖ Writing a Formal Use Case

• The typical outline for formal use cases can be in following manner
• The goal in context identifies the overall scope of the use case.
• The precondition describes what is known to be true before the use case is initiated.
• The trigger identifies the event or condition that “gets the use case started”
• The scenario lists the specific actions that are required by the actor and the appropriate system
responses.
• Exceptions identify the situations uncovered as the preliminary use case is refined Additional
headings may or may not be included and are reasonably self-explanatory.

Every modeling notation has limitations, and the use case is no exception. A use case focuses on
functional and behavioral requirements and is generally inappropriate for nonfunctional requirements.
However, scenario-based modeling is appropriate for a significant majority of all situations that you will
encounter as a software engineer. There is a simple use case diagram in the following figüre.
 2. Data Modeling Concepts

Data modeling is the process of documenting a complex software system design as an easily understood
diagram, using text and symbols to represent the way data needs to flow. The diagram can be used as a
blueprint for the construction of new software or for re-engineering a legacy application. The most
widely used data Model by the Software engineers is Entity Relationship Diagram (ERD), it addresses
the issues and represents all data objects that are entered, stored, transformed, and produced within an
application.

• Data Objects

A data object is a representation of composite information that must be understood by software. A data
object can be an external entity (e.g., anything that produces or consumes information), a thing (e.g.,
a report or a display), an occurrence (e.g., a telephone call) or event (e.g., an alarm), a role (e.g.,
salesperson), an organizational unit (e.g., accounting department), a place (e.g., a warehouse), or a
structure (e.g., a file).

For example, a person or a car can be viewed as a data object in the sense that either can be defined in
terms of a set of attributes. The description of the data object incorporates the data object and all of its
attributes.

A data object encapsulates data only there is no reference within a data object to operations that act on
the data. Therefore, the data object can be represented as a table as shown in following table. The
headings in the table reflect attributes of the object. Tabular representation of data objects in the
following figüre.
 • Data Attributes

Data attributes define the properties of a data object and take on one of three different characteristics.
They can be used to (1) name an instance of the data object, (2) describe the instance, or (3) make
reference to another instance in another table.

• Relationships

Data objects are connected to one another in different ways. Consider the two data objects, person and
car. These objects can be represented using the following simple notation and relationships are 1) A
person owns a car, 2) A person is insured to drive a car. There is a Relationships between data objects
in the following figure.

3. Class-Based Modeling

Class-based modeling represents the objects that the system will manipulate, the operations that will be
applied to the objects to effect the manipulation, relationships between the objects, and the
collaborations that occur between the classes that are defined. The elements of a class-based model
include classes and objects, attributes, operations, class responsibility collaborator (CRC) models,
collaboration diagrams, and packages.

• Identifying Analysis Classes

We can begin to identify classes by examining the usage scenarios developed as part of the requirements
model and performing a “grammatical parse” on the use cases developed for the system to be built.

Analysis classes manifest themselves in one of the following ways:

• External entities (e.g., other systems, devices, people) that produce or consume information to
be used by a computer-based system.
• Things (e.g., reports, displays, letters, signals) that are part of the information domain for the
problem.
 • Occurrences or events (e.g., a property transfer or the completion of a series of robot
movements) that occur within the context of system operation.
• Roles (e.g., manager, engineer, salesperson) played by people who interact with the system.
• Organizational units (e.g., division, group, team) that are relevant to an application.
• Places (e.g., manufacturing floor or loading dock) that establish the context of the problem and
the overall function of the system.
• Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a class of objects or
related classes of objects.

Attributes describe a class that has been selected for inclusion in the requirements model. The attributes
that define the class that clarify what is meant by the class in the context of the problem space.

To develop a meaningful set of attributes for an analysis class, you should study each use case and select
those “things” that reasonably “belong” to the class.

Operations define the behavior of an object. Although many different types of operations exist, they
can generally be divided into four broad categories: (1) operations that manipulate data in some way
(e.g., adding, deleting, reformatting, selecting), (2) operations that perform a computation, (3) operations
that inquire about the state of an object, and (4) operations that monitor an object for the occurrence of
a controlling event. There is a Class diagram for the system class in the following figure.