Verify Requirement

After requirements being specified and modelled, they must be verified if:

  • Quality standards are met; and
  • They are usable to other stakeholders.

In gist, verify requirement is to ensure requirement is stated correctly.

The question is: what is the “quality standards” and how can we know requirement “usable to other stakeholders”?

For the first question, in BABOK v3, IIBA lists 9 characteristics which are quite common to assess quality of requirement:

  • Understandable: represented using common terminology of the audience. Each level of requirements targets at the different stakeholders. As a results, terminologies used for each level might be different. That’s why previously I’ve recommended using user-friendly words for Business Requirement, but Technical Writing style must be strictly applied for Functional Requirement. This characteristic ensures requirements “usable to other stakeholders”.
  • Complete: enough to guide further work and at the appropriate level of detail for work to continue. The level of completeness required differs based on perspective or methodology, as well as the point in the life cycle where the requirement is being examined or represented. A quite common scenario that I’ve seen of this is lacking of description for alternative or exception cases. People are very focused on what happens with the main flow (e.g. click on the OK/Submit/Save button), but sometimes they forget about extension (alternative/exception) flow (e.g. click on the Cancel/Reject button). Some components of a form, or the link between stages within a workflow, sometimes, are also being forgot.
  • Feasible: reasonable and possible within the agreed-upon risk, schedule, and budget, or considered feasible enough to investigate further through experiments or prototypes – Or, requirement must be achievable in reality. Don’t promise a requirement of building a CRM system from scratch within 1 month or with 1k SGD, say it’s impossible instead.
  • Priotirized: ranked, grouped, or negotiated in terms of importance and value against all other requirements. In a bad case e.g. not enough budget for the project, lower priority requirement can be eliminated – and we cannot make any decision if requirement is not priotirized.
  • Concise: contains no extraneous and unnecessary content. Just document in-scope requirements, no more, no less. Also make sure all modelling notation and standard are followed.
  • Consistent: aligned with the identified needs of the stakeholders and not conflicting with other requirements. This consistence also have to be ensured throughout all levels of requirements, from Business Requirement to the lowest level of Solution Requirement (such as a Use Case). People will be very confused if the permission of an actor on a function is different between Permission Matrix and content of a Use Case.
  • Atomic: self-contained and capable of being understood independently of other requirements or designs. Each Use Case must be understandable without reading other Use Case. The similar thing happens with User Story.

Let’s take a look on this scenario: User submits a leave request, then it is approved by their direct manager or his delegate. Most likely, UC of Submit Request and UC of Approve Request will be catered. You might be confused: how can I understand UC of Approve Request without knowing about Submit Request? Surely you don’t need. In business term, you can do approval actions only after a request is submitted to you. In system term, you can perform approval function if a request is in a specific status – let’s assume here “Pending for Approval”. As long as this “Pending for Approval” status of request is mentioned in a pre-condition of UC Approve Request, you can fully understand this UC.

  • Unambiguous: the requirement must be clearly stated in such a way to make it clear whether a solution does or does not meet the associated need. Suppose there are 3 scenarios possibly happens, describe the associated action for each. Make sure that you don’t miss any possible scenario. Instead of saying “User can choose request type”, let’s say “The system allows user to choose request type as one of below options: A, B, C, D.” Describe about the results associated with each option, if they are different.
  • Testable: able to verify that the requirement or design has been fulfilled. Acceptable levels of verifying fulfillment depend on the level of abstraction of the requirement or design. If the requirement is not testable, how come we evaluate it later?

With these given characteristics, we can verify if a requirement is stated correctly. The verification activities are typically performed iteratively throughout the requirements analysis process. Make sure requirements are verified before sending for review or approval – and do the other verification round in case some changes must be made to the requirement and design.

One common technique we use for verifying requirement is Checklist. Checklist can be created based on organization standards and characteristics listed above. The level of details required differs based on perspective or methodology, as well as the point in the life cycle where the requirement is being examined or represented. Below is a checklist example for project using Use Case for requirement documentation.

SRS Review Checklist_v0.6

Thanks for reading!

Reference:

  1. IIBA. 2015. BABOK. Version 3.0.

 

Advertisements

2 thoughts on “Verify Requirement

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s