The specification of requirements is an essential aspect of the Requirements Engineering process. It is the third step, following Requirements Capture and Analysis. The purpose is to generate a document, or Requirements Specification, with the appropriate amount of information.

Quick Link to Specific Topic:

Activities of Requirement Specifications:

We learned about requirements elicitation in the previous section, where we worked through and extracted those needs from stakeholders and documents to understand what the as-is and to-be processes will look like.

We then went through requirement analysis, where we took those needs and articulated them in numerous ways so that parties, whether technical or business, could comprehend them, and we produced visual models to aid with that. This is the third step, requirement specification.

And essentially, what we’re doing here is classifying and breaking down the criteria that we have. So, if one requirement is a little long or complex, what is pushing them to split it up into numerous needs so it’s a little simpler to comprehend in plain and simple?

So we’re categorizing, generating needs, and prioritizing those requirements. And it’s critical that you prioritize requirements, that you assign a level of priority to them, because as the project progresses and you have a deadline for implementation, you don’t want to be at the point where you’re 90% through the project and realize you’re not going to get every single requirement in and now trying to circle back to the business to figure out what, you know, based on what you haven’t done, what you should do.

That is not the time to do it; you will go nowhere and face a lot of pushback. Prioritizing requirements is crucial at this point.

Finally, as the final stage of this requirement formulation process, you acquire validation of those requirements. So you go back to the company and make certain that the requirements are supported by at least a few stakeholders. This is to guarantee that you’re on the right track. This will be useful when you approach the final round of requirements approval.

Categorizing Requirements

One of the first steps in the requirements definition process is to classify requirements, which essentially involves dividing the needs into functional, nonfunctional or supplementary, and constraint requirements. And this is beneficial in a variety of ways.

Why Categorize Requirement?

  • Aids in documentation
  • Helps to prioritize
  • Assist Estimating the system cost.
  • Identifies areas that require further investigation.

Category of Software Requirements:

1. Functional Requirements:
	a. Things the product must do.
	b. Action product must take
2. Non-Functional Requirements:
	a. Properties or qualities the product must have
	b. How the product will behave
3. Constraints:
	a. Global Requirements :
		i. Purpose of the project
		ii. Users of the project.

You’ve elicited and now you’re going to go through in and categorize them all out.

Deriving Requirements

Your captured requirement is a document that may require additional development through derivation. And deriving requirements is all about three things:

  1. Adding further details
  2. Adding clarity to this requirement
  3. Removing ambiguity.

Techniques for determining requirement include:

• Parsing Requirement
• Interpreting Requirements
• Focusing Requirements
• Qualifying Requirements.

Parsing Requirements:

  • Breaking down requirements that are too broad.
  • Removing “and” from requirements
    • Risk is high that only one of the conditions will be tested
    • Hard to trace the requirement bug/ failure

Breaking Down Example:

  • Original Requirement:
    • “User-completed fields on tax forms shall be converted to electronic text documents.”
  • Parsed Requirements:
    • “The system shall be able to convert handwriting to text.”
    • “The system shall be able to convert machine print to text.”
    • “The system shall be able to electronically correct user-completed fields.

Interpreting Requirements:

  • Reduce generalness and ambiguity of stated requirements .

Interpreting Requirement Example:

  • Original Requirement:
    • “Each PC shall have state-of-the-art software installed.”
  • Interpreted Requirement:
    • “Each PC shall have Microsoft Office 2013 and Windows 10 installed.”
  • Parsed Requirements:
    • “Each PC shall have Microsoft Office 2013 installed.”
    • “Each PC shall have Windows 10 installed.”

Focusing Requirements:

  • Combine overlapping requirements into one focused requirement.

** Focusing Requirements Example:**

  • Original Requirement:
    • “Each PC must have a standard spreadsheet tool installed that runs in Windows.”
  • Focused Requirement:
    • “Each PC on the LAN shall have Microsoft Office Excel 2013.”

Qualifying Requirements:

  • Add a requirement to provide a method of verification or compliance .
  • ** Qualifying Requirements Example:**
  • Original Requirement:
    • “The xxx command must perform the following actions…”
  • Qualified Requirement:
    • “Each command shall be executed during system testing to demonstrate its functionality.”

Assigning Requirement Attributes

Why Assign Requirement Attributes?

  1. Clarification: More details
  2. Filtering: Filter by type functional, non-functional, constraints, and priority.
  3. Validation: Requirement met the business need.

Typical Attributes:

  • Unique Identifier: A unique identifier means that that identifier is unique to that specific requirement. It never changes.
  • Acceptance Criteria: what is the criteria that’s going to use to validate that that has been met?
  • Author: who’s actually writing the requirements?
  • Complexity: how hard is this going to be to implement in scale of 1 to 10?
  • Ownership: a group, the department that’s been affected by the requirement (Not the raiser).
  • Performance: If there is any performance attribute like how fast it should response.
  • Urgency: How quickly it is needed, in which iteration of agile approach?
  • Business Value: What business value it will add.
  • Status: Started, Confirmed, Developed, Tested, etc.
  • Type: Functional, Non- Functional, Constraints.
  • Priority: High, Medium, Low
  • Source: Who raise this, in case any clarification is needed to whom to consult?

Prioritizing Requirement

Why Prioritize Requirement:

Generally there are too many functions and features to implement within the project schedule and budget.

Prioritize Factors:

  • Value to the business
  • Value to the customer
  • Minimize cost to develop
  • Time to implement
  • Ease of technical implementation
  • Ease of business implementation
  • Obligation to some external authority

03 Step Prioritization Process:

  1. Define usefulness to business (critical, important, nice to have)
  2. Estimate cost (1-5 scale)
  3. Determine timeframe (1-5 scale)

Requirement Prioritization Best Practices:

  • ✅ Keep it simple
  • ✅ Business value reigns supreme
  • ✅ Remove prioritization away from politics
  • ✅ Prioritize (and re-prioritize) after each project iteration

Validate your requirement using SMART formula.

Business Requirement Document (BRD) Basics:

What is a Business Requirements Document?

It’s a document that houses all of the requirements, the business rules, the use cases, the version history, stakeholders, basically everything that you’re eliciting as part of the requirements of the project are documented within here.

Who prepares BRD?

Well it’s pretty obvious. The business analyst is responsible for filling out the BRD and making sure that it’s complete and accurate. And that’s really what’s utilized as you move into the next phases of the project to pass the requirements phase.

What is the use of BRD?

Number one it houses all of the requirements for the specific project. That’s the most critical use of the business requirements document is to house all of those requirements. Information of Stakeholder mapping, approvals, etc. will be kept here. Eventually the original system shall be design, implemented, and tested based on this document.

What is the standard format for BRD?

No there is no standard but it is pretty obvious that every organization use a BRD format based on their needs. But most of the information are almost similar.

One question that comes up a lot is ‘hey, when do I fill this out?’, you’ll see as we go through kind of an example template and format that it’s a pretty formal document. You have your elicitation, then you have your analysis, then your specification, then your validation. So in the elicitation that’s when you’re meeting with everyone, that’s when you’re doing all your different elicitation activities and at that time I’m not documenting inside of a BRD,

I’m trying to write good requirements, write SMART requirements because I don’t want to rewrite them all later, is when I start to put a lot of the details into the BRD and also in the specification phases when I kind of finalize that.

⬆ back to top

Buy me a coffee if you enjoyed this post. Your support helps me create more valuable content. Thank you!

"Buy Me A Coffee" "Buy Me A Coffee"

About Content Creator:

Hi, This is Rafayet Hossain

A Seasoned Business Systems Analyst, Project Manager, and SQA Engineer with experience in driving digital changes within organizations. I specialize in understanding business needs and developing software solutions to improve processes and drive growth. I am skilled in managing projects, analyzing data, and ensuring quality in the final product. I am passionate about using my expertise to help organizations reach their goals and succeed. Let’s work together to improve your business and drive success. Contact me for any inquiries or projects.

👉 For Any Query or Assignment Contact: :

Linkedin Gmail

All Posts on Business Analysis:

Click on any of the desired links to directly access the information.

Enjoy !!! See Yaaa, Next.

Diary