Introduction

In the specification activity, also known as requirements engineering, the goal is to identify and understand the needs and requirements for the software being developed.

The process of gathering, analyzing, specifying and validating the requirements is called Requirements Engineering.

This activity sets the foundation of the software development, it helps defining the scope, constraints, and objectives of the project.

It also helps identifying the stakeholders and the users of the software.

---

First it is good to mention that there are different types of requirements that can be identified during the specification activity, including:

1. Functional requirements:

These describe the specific actions or features that the software should be able to perform or the user will do to the system.

It includes two types:

1. User Requirements: User requirements describe the functionality that the software system must provide from the user's perspective. User requirements are typically expressed in terms of high-level features and capabilities that the software system should provide. Some examples and diagrams used:

• Use case Diagram: A diagram that shows a system and user actions as circles.

• User stories: "As a [user role], I want [goal or objective], so that [reason or benefit]."

• Activity diagram: A diagram that also shows sequence of activites with arrows and order.

• UI/UX Prototype: Also, you can start making the User interface design as an initial prototype.

1. System Requirements: System requirements describe the functionality that the software system must provide from a technical perspective. System requirements are typically expressed in terms of low-level technical details and are focused on how the software system should operate. Some examples and diagrams used:

• Requirement template: "The software system shall [perform a specific action or function] under [specific conditions or constraints]."

• Sequence diagram: A diagram that shows sequence of activites and actions on the system.

• State diagram: A diagram that shows sequence and details of activites, a much more detailed version of activity diagram.

• UI/UX Prototype: Also, you can start finishing the User interface design and add more details after making an initial prototype from the user requirements (or just start making it in this stage).

2. Non-functional requirements:

These describe the overall characteristics and quality of the software (Quality Attributes), on the other side also describe constraints that is made by stakeholders or others (Constraints). Examples include reliability, security, performance, usability, and scalability.

They define how the software should perform, rather than what the software should do.

2.1. Quality Attributes Quality Attributes can be grouped into 3 categories:

2.1.1. Product requirements: These describe how the software should perform, and are related to the technical aspects of the product.

They include subtypes such as:

• Performance requirement: These describe how well the software should perform in terms of speed, scalability, and throughput.

• Security requirements: These describe how well the software should protect against security threats and vulnerabilities.

• Reliability requirements: These describe how well the software should be able to operate without errors or failures.

2.1.2. Organizational requirements: These describe how the software should be developed, deployed and maintained, and are related to the organization.

They include subtypes such as:

• Maintainability requirements: These describe how easy it is to maintain the software.

• Portability requirements: These describe how easy it is to move the software to a different environment or platform.

• Reusability requirements: These describe how easy it is to reuse the software components.

2.1.3. External requirements: These describe how the software should interact with external systems and environments.

They include subtypes such as:

• Interoperability requirements: These describe how well the software can exchange information and work with other systems.

• Accessibility requirements: These describe how well the software accommodates users with disabilities.

2.2. Constraints: These are factors that restrict or limit the design and development of the software.

They can be technical, organizational, or environmental.

Examples include:

• Technical constraints: These include limitations imposed by the technology or platform that the software is being built on.

• Organizational constraints: These include limitations imposed by the organization, such as budget, time frame, or available resources.

• Environmental constraints: These include limitations imposed by the environment, such as network infrastructure or legal regulations.

3. Business requirements:

These define the business objectives that the software should support and align with.

They describe the business needs that the software is being developed to address.

Examples include being able to increase sales, being able to reduce costs, or being able to improve customer satisfaction.

---

Requirements engineering is a superset of two subtypes:

• Requirements Development

• Requirements Management

---

Requirements Development:

Requirements development is the process of defining a project's scope, and it has a process of 4 activities:

1. Requirements Elicitation:

This is the process of gathering and collecting information about the requirements from stakeholders, and users through various techniques such as interviews, questionnaires, observations, and workshops.

2. Requirements Analysis:

This is the process of analyzing, interpreting, and understanding the requirements collected during elicitation. The goal of this process is to identify any ambiguities, inconsistencies, or gaps in the requirements.

3. Requirements Specification:

This is the process of formally documenting the requirements in a clear and concise manner. The goal is to communicate the requirements to all stakeholders in a consistent way.

4. Requirements Validation:

This is the process of checking and verifying that the requirements meet the needs of the stakeholders and are complete, consistent, and accurate.

---

Requirements Management:

Requirements Management is the process of defining, documenting, analyzing, tracing, prioritizing, agreeing, and controlling the changing requirements of a project throughout its life cycle.

It includes all activities that maintain the integrity, accuracy, and currency of requirements agreements throughout the project.

There are core activites that are categorized into 4 categories:

1. Version Control:

This activity involves keeping track of different versions of the requirements document and maintaining a history of changes.

2. Change Control:

This activity involves managing and controlling changes to the requirements throughout the development process.

3. Requirements Status Tracking:

This activity involves keeping track of the current status of each requirement throughout the development process.

4. Requirements Tracing:

This activity involves tracing the relationship between the requirements and other artifacts in the project such as design, code, and test cases.

---

In The End:

Requirements shouldnt be just telling we need this or this, there are characteristics for perfect quality attributes:

• Unambiguous

• Correct

• Complete

• Consistent

• Testable

• Traceable

• Relevant

• Feasible

• Modifiable

• Prioritized

Also, ways to write a good quality attribute, ASR Utility Trees, Extracting quality attributes from Bussiness goals instead of asking what needed.

Bad Quality Attribute: The software system should be fast.

Better Quality Attribute: The software system should respond to user requests within 3 seconds.

---

Jobs:

Roles involved in Specifying the requirements:

1. Business Analysts:

These professionals are responsible for understanding the business needs of the organization and how the software will support them.

They work closely with stakeholders to gather, analyze and document requirements.

2. Systems Analysts:

These professionals are responsible for understanding the technical requirements of the system and how the software will support them.

They work closely with developers to gather, analyze and document requirements.

3. Project Managers:

These professionals are responsible for the planning and execution of the project.

They work closely with the stakeholders and the development team to ensure that the requirements are met.

4. UI/UX Designers:

Those designers may take requirements and design a User Interface for architects and developers.

---

What's Next?

Next activity is the Development, requirements here play a very important role on making the development better.