How to Write Requirements from Scratch?

The essence of requirements engineering is to clarify requirements, the set of information shared by all stakeholders (analysis, UI/UX, development, test and POC teams, and the end-user).

So how do we write requirements from scratch, how do we clarify the requirements?

They have formalized it, and they have collected it in 4 steps.

1. Capturing
2. Analysis
3. Spesification
4. Validation

To explain these 4 steps

Step 1 Capturing

The step where we get the requirements from the user, and there are 2 basic ways to do that.

1.1. Strip

We have a technical specification, statement of work, or OCD (Operational Concept Document) that describes what the user will do. When there are documents, the method by which we extract requirements from these documents is the Strip Method.

So how do we apply this method?

We read each statement in the document and decide if this is a requirement. These documents usually have a story dimension and a comment dimension; it should be like this, this is what it does here. By removing unnecessary details, we remove only the statements that are considered to be requirements. We add these statements to the draft requirement library we call requirement database; “this statement may be a requirement, write it to the requirement database. This statement cannot be a requirement, don't write it.” we do the strip operation. In the requirement database, we apply this method by adding the user's comments to our requirement database by marking that it is supporting text and not a requirement.

1.2.Elicitation

A method of understanding the user's needs from the user himself/herself, which we use when we have the opportunity to speak verbally with the user.

So how do we apply this method?

They have formalized this too.

1.2. 1. Define Resource Requirement

Who can I learn this requirement from? Person A, Administrator, System Administrator, whoever it is, is our first job to identify them.

1.2.2. Question Step

To understand the user's expectations from the system, we ask questions to the user by looking at the systems they use, if they have any, seeing the manual work they do with the user in their own work environment, listening to their requests for improvement, and looking at the problems there if they have units such as a help desk. Usually, the user responds indirectly, we ask them to elaborate more. User A says something, user B says something, and there are blurred lines. We try to solve these. We make mockup designs to increase clarity. After confirming, we add the details we receive from the user into sentences and add them to our requirement database.

After the Capture phase, we have a draft requirement database.

Step 2 Analyzing

They called the stage of analyzing our draft requirement database as Analyzing. They have formalized this too.

2.1.Decomposition

It is a program where we translate complex long statements in our requirement database into smaller stand-alone meaningful statements and create a The section where we create child requirements from the statement.

2.2.Deduplication of Repetitions

After the decomposition process, there is duplication in some statements. At this stage, we deduplicate the repeated requirements.

2.3.Clarification

After deduplicating repeated requirements, you may notice that some statements are not clear. During the clarification phase, we work on making these statements clear. If the requirement is obtained from the user, we clarify it with the user; if it is extracted from documents, we delve into the documents for further details to make it clear. If the source cannot be accessed, we clarify it by making assumptions with the Project Manager and Technical Manager. We also document the requirements that we clarify together.

2.4.Elimination

This is the stage where we derive a new requirement from an existing one. It is crucial to ensure that the derived requirement is not created arbitrarily. It must always be based on a document or another requirement. It should not be forgotten that a requirement without a clear relationship to another could lead to additional development costs for features the user did not request and cause delays in the project timeline.

2.5.Categorization

As the name suggests, this is the stage where we write the created requirements in a categorical form. Categorizing requirements is important to ensure easier consistency checks, opening tasks with 100% coverage, facilitating development and test case preparation, tracking project metrics more easily through categorical attributes, and making project management more efficient.

After the analyzing phase, we have a refined draft requirement database.

Step 3 Spesification

They call the stage of documenting the draft requirement database as Specification.

Requirements define the need of the user, the system. It does not define how to do it. If you are talking about a software object or a database in a requirement, you are doing wrong, these are how to do the job. The reason we don't put them in the requirement database is that they affect the solution. In Requirement, if I write “.... will allow you to save it by clicking the save button in the lower right corner.”, it will affect whether I put the button on the left side or somewhere else. When we write requirements, we focus only on the need. The customer may have design requirements, of course, we keep them separate. However, if there is no design requirement from the customer, we are only trying to define what we will do in the requirement, we do not include how we will do it in the definition.

How we make this definition effectively, I mentioned in my medium article I wrote before (Link). You can review it by clicking on the link.

With the specification phase, we have completed documenting the requirements.

Step 4 Validation

This is the stage where I validate the documented requirements with stakeholders. First, I validate with the software developer within the company to see if it can be done. Then, I validate with upper management.

Afterward, we validate with the customer and establish the baseline, confirming that the system to be developed will meet these requirements. This way, we close uncontrolled changes. From this point on, any changes are made in a controlled manner, and we proceed with the process by writing Engineering Change Proposals (ECPs) and Contract Change Proposals (CCPs). (I plan to explain how to write ECPs and CCPs in a separate post.)

Finally, it should not be forgotten that in order to prevent the development of the wrong product and unnecessary development costs, as the requirements are developed, verification is carried out on the intermediate products, i.e., checking whether the resulting product is built according to design documents, standards, and specifications and works without errors. Then, validation is performed by showing the product to the end user to ensure it works under real-world conditions and meets user expectations, and any additional requests from the end user are recorded. This process should proceed with mutual agreements.

Thanks for reading so far, I hope it was engaging for you.