Software Requirements Analysis: A Comprehensive Guide
1. Introduction to Analysis
1.1 General
A fundamental stage in the software life cycle is analysis. Analysis examines the system based on requirements. To analyze requirements, they must have been previously obtained through requirements determination or requirements engineering.
1.1 Definition of Analysis
Analysis is the process of studying user needs to define system, hardware, or software requirements, and the process of studying and refining these requirements.
1.1 Requirements Engineering
Requirements engineering is the first phase of the software life cycle where specifications are created. From informal ideas, functional requirements and non-functional requirements, along with criteria to measure their achievement, should be obtained and documented.
The process of developing the requirements specification is called requirements engineering. It places growing importance on the correct understanding (procurement), documentation (specification), and validation of user and client needs, as well as quality measurement systems based on user satisfaction.
1.3 Requirements
A requirement is a condition or capability needed by the user to solve a problem or achieve a specific goal. While the term requirement appears simple, it’s common to find it qualified with adjectives that can be initially confusing.
Scope
Scope indicates the context in which a requirement should be understood. A system scope indicates the requirement should be met at the system level, encompassing both hardware and software. A software scope means the requirement pertains only to the system software. A hardware scope means it only affects the hardware.
Defining Feature of a Requirement
This dimension classifies requirements based on the nature of the specified system property. The most common classification distinguishes between functional requirements (what the system should do) and non-functional requirements (other system characteristics). This distinction can sometimes be unclear, as a requirement might fall into multiple categories.
Audience
Audience indicates who the requirement is intended for. Generally, there are two types of audiences: customers and users who may not be trained in software engineering, and software developers. Customer-oriented requirements (C-requirements) are written from the perspective of customers and users, while developer-oriented requirements (D-requirements) are written for developers.
Representation
Representation establishes how requirements are defined. Categories are typically formal, semi-formal, or informal. Formal representations have rigorous semantics and syntax. Semi-formal representations use models to facilitate understanding among participants. Informal representations use natural text, videos, images, voice, and sounds to describe the system.
1.4 Objective
The objective is to build a precise software requirements specification (SRS) that describes what the system should do, without detailing how. The SRS should include both C-requirements and D-requirements. Some methodologies advocate separating these into two documents: the System Requirements Document (SRD) or catalog of requirements outlining C-requirements, and the SRS itself, which identifies D-requirements. Creating an SRS involves software engineers (analysts), customers, and users.
1.7 Principles of Analysis
- Represent and understand the scope of the problem information.
- Develop information models representing the functional components and system performance.
- Subdivide models to progressively or hierarchically reveal details.
- Focus on essential information for implementation.
1.7.1 Information Representation
Three ways to represent information are: information flow, information content, and information structure.
1.7.2 Model Construction
The goal is to manage complexity. Focus on what the system does. Use graphical representations to complement textual information. Model types include logical and physical.
1.7.2.1 Why Model?
Models are built for various purposes. The aims of building models include: testing a physical entity before building, customer communication, visualization, reducing complexity, and structuring ideas.