Software Requirements and Structured Analysis

Objectives

Explain software requirements and the role of a system analyst.
Describe the requirement engineering process.
Apply the concepts of structured analysis.

Introduction

Software requirements are descriptions of the features and functionalities of the target system.
Requirements convey the expectations of users from the software product.
Requirements can be known or unknown, expected or unexpected, from the client’s point of view.

3.1 Software Systems Analyst

A system analyst in an IT organization is a person who analyzes the requirements of a proposed system and ensures that these requirements are documented properly and correctly.
The role of an analyst starts during the Software Analysis Phase of SDLC (Software Development Life Cycle).
It is the responsibility of the analyst to ensure that the developed software meets the client's requirements.

Responsibilities of System Analysts

Analyzing and understanding the requirements of a developing software/project.
Understanding how the software/project will contribute to the organization’s objectives.
Identifying sources of requirements.
Validating the requirements.
Developing and implementing a requirement management plan.
Documenting business, technical, process, and product requirements.
Coordinating with clients to prioritize requirements and remove ambiguity.
Finalizing acceptance criteria with the client and other stakeholders.

3.2 Requirement Engineering

The process to gather software requirements from the client, analyze, and document them is known as requirement engineering.
The goal of requirement engineering is to develop and maintain a ‘System Requirements Specification’ document.

3.2.1 Requirement Engineering Process

A four-step process:
1. Feasibility Study
2. Requirement Gathering
3. Software Requirement Specification
4. Software Requirement Validation

3.2.1.1 Feasibility Study

When a client approaches an organization for a desired product, they usually have a rough idea of the functions and features expected from the software.
Analysts conduct a detailed study to determine whether the desired system and its functionality are feasible to develop.
This feasibility study focuses on the organization's goals.
It analyzes whether the software product can be practically materialized in terms of implementation, contribution to the organization, cost constraints, and alignment with the organization's values and objectives.
It explores technical aspects of the project and product, such as usability, maintainability, and integration ability.
The output of this phase should be a feasibility study report containing adequate comments and recommendations for management to decide whether to undertake the project.

3.2.1.2 Requirement Gathering

If the feasibility report is positive, the next phase involves gathering requirements from the user.
Analysts and engineers communicate with the client and end-users to understand their ideas about what the software should provide and which features they want to include.

Requirement Elicitation Techniques

Requirement Elicitation is the process of finding out the requirements for a developing software system by communicating with the client, end-users, system users, and others who have a stake in the software system development.
Various methods to find and finalize requirements:
- Interviews: Structured conversations where one participant asks questions and the other provides answers. Strong method to collect requirements. Types include:
  - Structured (closed) interviews: Information to gather is decided in advance.
  - Non-structured (open) interviews: Information to gather is not decided in advance; more flexible and less biased.
  - Oral Interviews
  - Written Interviews
  - One-on-one interviews: Held between two persons.
  - Group interviews: Held between groups of participants. Help uncover any missing requirements as a group of people are involved.
  - Example of Structured (Closed) Interviews:
    1. Which of the following would you say is the one best thing about the information system you currently use to do your job?
      a. Having easy access to all the data you need
      b. The system’s response time
      c. The ability to run the system concurrently with other applications.
    2. How many telephone orders are received per day?
    3. How does the customer place an order?
    4. How many personal computers do you have in this department?
    5. Do you review the reports before they are sent out?
    6. How many hours of training does a clerk receive?
    7. Is the calculation procedure described in the manual?
    8. How many customers ordered products from the Web site last month?
  - Example of Non- Structured (Open) Interviews:
    1. What would you say is the best thing about the information system you currently use to do your job?
    2. What do you think about the way invoices are currently processed?
    3. What are the problems encountered daily?
    4. How is this task performed?
    5. What added features would you like to have in the new billing system?
    6. What are the critical objectives of your department?
- Surveys: Organizations may conduct surveys among various stakeholders by querying about their expectations and requirements from the developing system.
- Questionnaires:
  - A document with a pre-defined set of objective questions and respective options provided to all stakeholders to answer, which are collected and compiled later.
  - A problem with this technique is that if an option for some issue is not mentioned in the questionnaire, the issue might be left unattended.
- Task Analysis:
  - A 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 a certain operation, it is studied, and requirements of the proposed system are collected.
- Domain Analysis:
  - Every software belongs to some domain category.
  - Expert people in the domain can help analyze general and specific requirements.
- Brainstorming:
  - It is an informal debate held among various stakeholders, and all their inputs are recorded for further requirements analysis.
- Prototyping:
  - Prototyping will build a user interface without adding detail functionality for users to interpret the features of developing software.
  - It helps give a better idea of requirements.
  - If there is no software installed at the client’s end for the developer’s reference and the client is unaware of its own requirements, the developer creates a prototype based on initially mentioned requirements.
  - The prototype is shown to the client, and feedback is taken.
  - The client feedback serves as an input for requirement gathering.
- Observation:
  - A team of experts visits the client’s organization or workplace.
  - They observe the actual working of the existing systems.
  - They observe the workflow at the client’s end and how execution problems are dealt with.
  - The team itself comes to some conclusions which aid in forming requirements expected from the software.

Summary of the Requirement Gathering Techniques

Interview: A structured conversation where one participant asks questions, and the other provides answers.
Survey: To ask in order to collect data for the analysis of some aspect of a group or area.
Questionnaires: A document with a pre-defined set of objective questions and respective options.
Task Analysis: Understanding tasks that are required for decision-making.
Domain Analysis: The process of analyzing related software systems in a domain to find their common parts.
Brainstorming: An informal debate among stakeholders where all inputs are recorded.
Prototyping: Building a user interface without adding detail functionality.
Observation: Immersion to the company in order to gain information.

3.2.1.3 Software Requirement Specification (SRS)

SRS is a document created by a system analyst after the requirements are collected from various stakeholders.
SRS defines how the developing software will interact with hardware, external interfaces, speed of operation, response time of the system, portability of software across various platforms, maintainability, speed of recovery after crashing, security, quality, limitations, etc.
The requirements received from the client are written in natural/simple language.

SRS Features:

User requirements are expressed in natural/simple language.
Technical requirements are expressed in structured/technical language, which is used inside the organization.
Design descriptions should be written in Pseudo code.
Format of Forms and GUI screen prints.
Conditional and mathematical notations for DFDs etc.
It is the responsibility of the system analyst to document the requirements in technical language so that they can be understood and useful for the software development team.
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

Software Requirements

We should try to understand what sort of requirements may be retrieved in the requirement elicitation phase and what kinds of requirements are expected from the software system.
Software requirements are categorized into two categories:
- FUNCTIONAL REQUIREMENTS: What a system does or performs.
  - Refers to the processes that the system performs and the data it needs or information it produces.
- NON-FUNCTIONAL REQUIREMENTS: How well the system does it within the design and resource constraints.
  - How the system behaves.

Functional Requirements:

These are requirements related to the functional aspect of software. They define functions and functionality within and from the software system.
- Examples:
  - Search option given to students to search topics from various resources.
  - Users should be able to mail any report to management.
  - Users can be divided into groups, and groups can be given separate rights.
  - Should comply with business rules and administrative functions.
  - Software is developed keeping downward compatibility intact.

Examples of Functional Requirements

The system must be able to search for available inventory.
The system must be able to check clash of timetable.
The system must be able to display registered timetable.
The system must allow registered customers to review their order history.
The system must check incoming customer orders for inventory available.
The system must retain customer order history for three years.
The system must include real-time inventory levels in all warehouses.
The system must print timetable.
The system must save all marks every semester.

Non-Functional Requirements

Requirements not related to the functional aspect of software are non-functional requirements. They are implicit or expected characteristics of software that users make assumptions about.
Non-functional requirements include:
- Security
- Storage
- Configuration
- Performance
- Cost
- Interoperability
- Flexibility
- Disaster recovery
- Accessibility

Examples of Non-Functional Requirements

Cost
- The cost of the backlog item is in product compliance entry.
- Adding five modules to the system is still within budget stocks.
- The system has restrictions on immediate and/or long-term costs.
Performance
- The CIMS (Customer Information Management System) must handle 2,000 registrations per second.
- The response time for all requests must be less than 1 second.
- The system must handle 1,000 transactions per second.
- The system has the capacity to refresh the screen every 15ms after any transactions. $(\text{ms} = \text{milliseconds})$
- The interaction between the user and the system should not exceed 2 seconds.
- The system must be able to handle a peak load of thirty simultaneous users with no more than five-second response times.
Flexibility
- The system can run on handheld devices.
- He will receive a verification e-mail, which has a link to the website.
- The purchasing system must run on a bar code scanner.
- The system must have a verification e-mail, which has a link to the website.
Interoperability
- The advising and registration must work dependently to one another through LAN (Local Area Network).
- The CIMS has the ability to share a database connection to UTAS (University of Technology and Applied Sciences).
Configuration
- The Online Shopping must be able to "Update Customer"; users may choose whether to display the previous name the customer has been known by.
Disaster Recovery
- The system must have less than 1-hour downtime per three months survivability.
- The system automatically restarts within 5 seconds after a virus has been detected.
- Upon payment, the card is automatically disabled if power or battery is shut down.
- If data or the system is corrupt, it has an automatic backup system.
- The CIMS must be able to restart by itself within 10 minutes after a power interruption.
Accessibility
- The system must be user-friendly.
- The system must be accessible to all types of users.
- The system has page navigation.
- The CIMS has a HELP feature.
- The System has A FAQ so that the user can easily ask on the system.
- The system provides training help.
Security
- The system Shall be password protected.
- Only the ADMIN can access the File Maintenance Module.
- Only direct managers can see personal records of staff.
- The system shall ensure that data is protected from unauthorized access.
- The system shall include a user authorization procedure where users must identify themselves using a login name and password.
Storage
- The database capacity is 5GB. $(\text{GB} = \text{Gigabytes})$
- The storage of each transaction is 500K megabytes. $(\text{K} = \text{Kilo})$
- The transaction of CIMS is running using 64GB RAM. $(\text{GB} = \text{Gigabytes})$

3.2.1.4 Software Requirement Validation

After the requirement specifications are developed, the requirements mentioned in this document are validated (Confirmed).
Users might ask for illegal, impractical solutions, or experts may interpret the requirements incorrectly, so validation is required.

Requirements can be checked against the 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.

3.3 Structured Analysis

Structured Analysis is a development method that allows the analyst to understand the system and its activities in a logical way.
During Structured Analysis, various tools and techniques are used for system development.

The following tools includes:

Data Flow Diagrams
Decision Tables
Structured English

3.3.1 Data Flow Diagram (DFD)

Data Flow Diagram (DFD) is an analysis tool used to capture the flow of input data through a system to output results through a sequence of functional transformations.
It is a graphical representation of the flow (processes) of data in an information system.
It shows incoming data flow, outgoing data flow, and stored information.
Difference between DFD and Flowchart:
- The flowchart shows the flow of control in program modules.
- DFDs depict the flow of data in the system at various levels. It shows how data moves through an information system.
- It does not show program logic.

Importance of Data Flow Diagram

Provides an easier way to understand all the technical and non-technical transformation functions of a system.
Provides a high-level system overview and complete boundary definitions or connections to other systems.
Provides a detailed representation of system functional components.
It checks the completeness of the analysis phase to meet the information system (project) requirements.
It aids system developers/designers and others during initial analysis stages to visualize a current system to meet any new requirements.

Types of DFD:

Logical DFD: Concentrates on the system process and flow of data in the system. Focuses on the business and how the business operates.
Physical DFD: Shows how the data flow is implemented in the system, including the hardware, software, files, and the people involved in the system. It is more specific and closer to the implementation.

Types of DFD Development

Ideally, systems are developed by:

Analyzing the current system (the current (old) logical DFD).
Then, adding the features that the new system should include (the proposed logical DFD).
Finally, the best methods for implementing the new system should be developed (the physical DFD).

Levels of DFD

Context Flow Diagram- Level 0

Diagram 0- Level 1

Child Diagram- Level 2

DFD Components/Symbols

Symbol Name	Yourdon Symbols	Gane and Sarson symbols
Process	Circle	Rectangle with Rounded Corners
Data Flow	Arrow	Arrow
Data Store	Open-ended Rectangle	Rectangle with one open side
External Entity/ Termintor/ Source/ Sink	Square	Double Square

External Entity or Entity

Describes the components that interact within the system.
Defines the source and destination of information/data that enter and leave the system.
External entities are also known as terminators, sources/sinks, and actors.
person, group, department, machine, or any system that either produce/originates (source) or receives (sink) information/data.
An external entity represents persons, processes, or machines that produce data to be used by the system or receive data that is output by the system.
It can send data to or receive data from the system.
Examples of external entities include:
- End User such as Student, Customer, Client
- Purchasing Department
- Inventory System
Must be named with a noun.
May be used more than once on a given DFD to avoid crossing data flow lines.

Source

Entity that supplies data to the system.

Sink

Entity that receives data from the system.

Process

A discrete action that transforms input data to output data so they are transformed, stored, or distributed.
Means that some action or group of actions takes place to show data transformation or change.
All processes must have inputs and outputs. In other words, a process is asked to do something and then must deliver.
Each process is always