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:
- Categorizing Requirements
- Deriving Requirements
- Assigning Requirement Attributes
- Prioritizing Requirement
- Validate your requirement using SMART formula.
- Business Requirement Document (BRD) Basics:
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:
- Adding further details
- Adding clarity to this requirement
- 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?
- Clarification: More details
- Filtering: Filter by type functional, non-functional, constraints, and priority.
- 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:
- Define usefulness to business (critical, important, nice to have)
- Estimate cost (1-5 scale)
- 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.
Enjoy !!! See Yaaa, Next.