Requirements

Objective

Introduction to the main stages of the system development life cycle.
Understand the importance of requirements analysis in software development.
Identify functional and non-functional requirements.
Define system functions and actors.

Development Life Cycle

The typical 7 stages of the system development life cycle (opens in a new tab) (SDLC) are planning and feasibility, requirements analysis, design and prototyping, software development, system testing, implementation, and maintenance. Alternatively, the aforementioned processes are sometimes split into 5 phases of the system development life cycle: planning, analysis, design, implementation, and maintenance.

SDLC is not a methodology per se, but rather a description of the phases that a methodology should address. The most common development methodologies are Iterative (opens in a new tab), Spiral (opens in a new tab), Agile (opens in a new tab), Scrum (opens in a new tab), Kanban (opens in a new tab), V-model (opens in a new tab), Waterfall (opens in a new tab), Lean (opens in a new tab), and eXtreme Programming (opens in a new tab). The choice of methodology depends on the project and the team, as each methodology has its own strengths and weaknesses.

Analysis

Requirements analysis (opens in a new tab) focuses on the tasks that determine the needs or conditions to meet the new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating, and managing software or system requirements.

Requirements analysis is critical to the success or failure of a systems or software project. The requirements should be documented, actionable, measurable, testable, traceable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.

Elicitation

Requirements elicitation (opens in a new tab) is the practice of researching and discovering the requirements of a system from users, customers, and other stakeholders. It is a set of activities that help identify the needs of the stakeholders and the requirements of the system. The practice is also sometimes referred to as “requirement gathering”.

Before requirements can be analyzed, modeled, or specified they must be gathered through an elicitation process. This process is a critical step in the software development process, as it helps ensure that the software meets the needs of the stakeholders. It involves gathering information from stakeholders about what they need from the software, and then using that information to create a set of requirements that the software must meet. Requirements elicitation is a part of the requirements engineering (opens in a new tab) process, usually followed by analysis and specification of the requirements.

The term elicitation is used in books and research to raise the fact that good requirements cannot just be collected from the customer, as would be indicated by the name requirements gathering. Requirements elicitation is non-trivial because one can never be sure to get all requirements from the user and customer by just asking them what the system should do or not do. Requirements elicitation practices include interviews, questionnaires, user observation, workshops, brainstorming, use cases, role playing, and prototyping.

Requirements

A functional requirement (opens in a new tab) describes what a software system should do, while a non-functional requirement (opens in a new tab) place coenstraints on how the system will do so. Non-functional requirements are often called the quality attributes of a system.

Non-functional requirements can be seen are cross-cutting through the functional requirements. They are usually related to the system as a whole, rather than individual functions. Non-functional requirements can be classified into several categories, such as usability, reliability, performance, and supportability.

Functional requirements are detailed in the system design (opens in a new tab) while non-functional requirements are detailed in the system architecture (opens in a new tab).

A product requirements document (opens in a new tab) (PRD) is a comprehensive document that outlines the purpose, features, functionality, and behavior of a product. It serves as a guide for stakeholders and the development team throughout the product lifecycle. The PRD typically includes the product vision, target users, functional and non-functional requirements, success metrics, constraints, and assumptions. It acts as a single source of truth that aligns business objectives with technical implementation, ensuring that all team members have a shared understanding of what needs to be built and why.

Exercise 1

Identify the main functional and non-functional system requirements.

Requirement	Type
Description	Functional/Non-functional

requirements.md

| Requirement | Type |
| :---------- | :--- |
|             |      |
|             |      |
|             |      |
|             |      |
|             |      |
|             |      |
|             |      |
|             |      |

Functions

A function is a list of actions or event steps typically defining the interactions between a role (actor) and a system to achieve a goal. A function must yield an observable result that is of value to the user of the system.

Actors

An actor represents a role of a user that interacts with the system that is being modeled. The user can be a human user, an organization, a machine, or another external system.

Actors do not necessarily represent specific physical entities but merely particular facets, that is, “roles”, of some entities that are relevant to the specification of its associated use cases. A single physical instance may play the role of several different actors and a given actor may be played by multiple different instances.

Exercise 2

Identify the main system functions along with the relevant actors that interact with those functions. Your goal is to write a table as follows:

Function	Actor
Book room	Customer Reservation Staff Payment Processor
Manage check-in	Desk Clerk Customer
Make payment	Customer Accountant

functions.md

| Function | Actors |
| :------- | :----- |
|          |        |
|          |        |
|          |        |
|          |        |
|          |        |
|          |        |
|          |        |
|          |        |

User Journeys

User journeys (opens in a new tab) define the motivations for using your system, the problems that your system solves for the user, the different phases of your system, and the experience from start to finish, as well as emotions and feelings that the user may have along the way.

Scenarios

Scenarios (opens in a new tab) can be defined as outlining specific areas of functionality. What does the system need from users for that particular scenario? What do users need from the system for that particular scenario?

If you think of a user journey as say, the book from start to finish, scenarios could be individual chapters. In other words, a scenario can be thought of as a singular situation and a journey can be a collection of scenarios that together form a narrative that defines the total experience of the users.

Structure

- functions.md
- requirements.md

Resources

1 Initiation 3 Use Cases