Organizing Requirements

In Requirement Organisation, you arrange the requirements to make it meaningful.

In this you:

• Categories the requirements (arrange the requirements into meaningful categories)
• Derive the requirements (add more clarity and minimize ambiguity)
• Prioritize requirements  (arrange the requirement based on business value urgency)
• Validate the requirements (Validating requirements at regular intervals from a few stakeholders helps you to stay on right track and also helps to get approvals on them later)

Categorizing Requirements

Why categorize requirements?

• It helps in documentation

Requirements are a huge list of action items. It’ll be difficult to work with them if they are in random order. Categorizing them arranges them in order and also helps to document them in a formal document e.g. BRD

• It helps in prioritization

It is easy to make decisions (e.g. assigning priority) on correctly arranged documents.

• It helps in estimating the system cost

Since we have a complete list of arranged and categorized requirements it will help the technical team to work out the system design. This will help to estimate the time and cost of the system.

It also helps the technical team to do trade-offs e.g. A requirement says that the response time should be one second. The technical team analyses the system and concludes that it is not feasible within the constraints. However, it can be done in 1.5 seconds. They can rearrange the system requirement, do trade-offs and give the time and effort cost for that additional half second gain. The business can then make a decision if they want to go ahead with the requirement.

• It helps to identify areas that require further investigation

E.g if there are no non-functional requirements then you can investigate further to find them.

 

Broadly the requirements can be divided into 3 main categories

• Functional
• Non-Functional
• Constraints

Deriving Requirements

Deriving Requirements is about 3 key things:

• Adding Further Details
• Adding Clarity
• Removing Ambiguity

4 techniques to derive a requirement

• Parsing Requirements
• Interpreting Requirements
• Focussing Requirements
• Qualifying Requirements

Use the above techniques to derive requirements with the right level of details and the least amount of ambiguity.

Parsing Requirement

In this technique, you break down requirements that are too broad

E.g

Original requirement:

• User should be able to create an account with the system

Parsed Requirements:

• User should be able to navigate to a registration page
• User should be able to fill the registration form
• Errors should be checked on the registration form
• User should be able to submit the form
• User should get a confirmation email
• User record should be created in the database

If a requirement has the term “and” in it then it may suggest that there are multiple requirements in it. Remove “and” from requirements because:

• Risk is high that only of the conditions will be tested
• Hard to trace the requirement bug/defect/failure

Interpreting Requirements:

This technique reduces the generalness and ambiguity of the stated requirement

E.g.

Original Requirement:

• The user registration form should have two-factor authentication for security

Interpreted Requirement:

• The user should be able to set a password and a phone number to receive a one-time-password

Parsed Requirements:

• The user should be able to set a password
• The user should be able to set a phone number to receive a one-time-password

Focussing Requirements:

In this technique you combine overlapping requirements into one focussed requirement

E.g.

Original requirement:

• A user should be able to sign up for a campaign

Focussed requirement

• An unregistered user should be able to register for the yearly company event

We can further group the above requirement with the previously mentioned user registration requirement

Qualifying Requirement

In this technique, we add a requirement to provide a method of verification or compliance.

By having a qualifying requirement we make the requirements testable.

E.g.

Original requirement

• The Admin should be able to perform the following tasks….. on the user data from the backend

Qualified Requirements:

• The admin should be able to perform the tasks on user data from the backend,  during system testing to demonstrate its functionality.

By adding the qualified requirement before the original requirement, you make all the operations mentioned in the original requirement testable.

Assigning Requirement Attributes

By assigning attributes to requirements you provide additional properties to requirements. This gives additional meaning to requirements which helps to efficiently work with them and test them.

Why assign attributes to requirements?

You assign attributes to requirements for:

• Clarification

These attributes give additional details e.g. the origin of the requirement, the business value associated with it, urgency, etc.

• Filtering

Requirements are a huge list of action items. Attributes help to find and sort requirements e.g. functional, non-functional, priority, business need, etc

• Validation

The attributes can help to validate if the requirement was met e.g. acceptance criteria, etc

Common Attributes:

• Unique Identifier

It uniquely identifies the requirement in the entire requirements document.

• Acceptance Criteria

They help to validate a requirement during testing

• Author

One of writes the requirement

• Complexity

It explains how difficult it would be to implement i.e. design and development. The values could be high, medium, low, numeric 1,2,3.., etc.

• Ownership

The group/team that gets affected by the requirement. It is not necessarily the person/group who gave the requirement.

• Performance

This attribute helps you to assign performance requirements if any. E.g. how quickly you want a feature/functionality to work; the response time should be less than 1 second, etc

• Urgency

This attribute provides info about quickly the business needs a requirement. This is especially important if it is an iterative project (e.g. Agile). The urgency attribute helps to assign the requirement to the appropriate iteration (phase) of the project. E.g The values could be high, medium, low, numeric 1,2,3.., etc.

• Business Value

This attribute is a quick description of the value provided by the requirement. One of its use could be: It can help you to drop a requirement from the project or from a particular phase based on the business value.

• Status

The values could be stated, confirmed, developed, tested, etc

• Type

The values could be functional, non-functional, supplemental, constraint, etc

• Priority

The values could be high, medium, low, numeric 1,2,3.., etc.

• Source

The attribute informs about who gave the requirement. This can be helpful if in the future you want any clarification on the requirement then you can approach the person/group who gave the requirement.

Prioritizing Requirements

Why?

Generally, there are several functions and features to implement within the project schedule, resources, and budget. Prioritization helps to select the most important ones that bring maximum business value.

Prioritization Factors:

• Value to the business

Value to the company that the project is being built for. It could be your company or another company.

• Value to the customer

It is the end-user of the project. It could be your company or a paying customer utilizing the project/product.

• Minimize cost to develop

The most cost-efficient way to develop the requirement (i.e. build the solution)

• Time to implement

The time before you can see Return on Investment.

• Ease of technical implementation

Is it technically feasible to implement based on time, cost, and resource.

• Ease of business implementation

How easy it is for a business to adapt based on a political standpoint, change standpoint, technical standpoint (e.g. if the system is too technical for the business to adapt), etc

• Obligation to some external authority

Based on some external law, regulation etc.

3 Step Prioritisation Process

Step 1:

Define business utility/benefits (Critical, Important, Nice to have)

• Critical – This has to happen. In its absence, the business cannot function.
• Important – This is important for business. However, in its absence, the business still can function.
• Nice to have – Everything else. In its absence, the business still can function.

At this point, you take into account only the usefulness to the business and nothing else like implementation difficulty, etc.

Step 2:

Estimate Effort (1-5 scale)

In this step, you estimate the effort required from the technical and business feasibility/complexity standpoints.

You can have a scale of 1-5 in which 1 is the least complex and 5 being the most complex.
You can then associate time with those points based on the duration of the project. E.g. If the project duration is six weeks then 1-on-scale could be 2 hours and the 5-on-scale could be 30 hours. If the project duration is six months then 1-on-scale could be 1 day and 5-on-scale could be 8 days.

Step 3:

Estimate Time Frame (1-5 scale)

In this step you estimate the ease of implementation.  A requirement could be less complex but may take a long time to implement.

You can have a scale of 1-5 in which 1 is the shortest time frame and 5 being the longest.

Now based on the above process you can filter the top requirements

E.g. Get all the requirements that have

• Step 1: Business Utility of “Critical”
• Step 2: Complexity of “1”
• Step 3: Implementation time of “1”

Best Practices for Requirement Prioritization:

• Keep it simple.

If someone asks that why a requirement important that you should quickly be able to give a justifiable answer e.g. Based on the aforementioned example you could say, “It is important because it is critical, less complex and easy to implement.”

• Business Value reigns supreme

Irrespective of whether you are a functional or technical BA, always focus on the business/customer.

Irrespective of the business or technical difficulties if a requirement is important for the business/customer then it has to be “done”.

• Remove prioritization away from politics

Don’t change the prioritization attributes to favor an individual or a group. Be open-minded and always think from the business’ perspective.

• Prioritize and re-prioritize after each project iteration

The business is always changing and so keep the priority levels up to date so that you are always working on those requirements that provide value to the business.

Validating Requirements

It doesn’t mean getting approvals for a requirement.

It means that requirements are SMART and valid.

You get the requirements validated from the stakeholders at regular intervals (e.g. after each project iteration) so that the requirements are always correct and have a defined purpose.

 

The post is  based on my notes and understanding from this BA tutorial