Capturing Requirement Attributes in Use Cases

The Guide to the Business Analysis Body of Knowledge? or the BABOK? Guide as popularly known, which is published by the International Institute of Business Analysis (IIBA) is the globally recognized standard for the practice of Business Analysis. It defines how industry practitioners playing any sort of analysis role and even business organizations should operate to deliver value to stakeholders through which to achieve superior business change or outcomes.

The BABOK? Guide defines Requirements as a condition or capability that is required in a solution that is developed to achieve a change in a business which is operating within a certain business context. This business need that may be to solve a problem or to make tap into an opportunity is what is documented as different types of requirements using requirements modeling techniques as appropriate.

I will not be talking about ‘types of requirements’ or ‘types of requirements modeling techniques’ here. I invite you to investigate more on this. I will today be talking about what requirement attributes are and how we can specify these when modeling requirements as use case descriptions. Again, I will not be discussing what a use case is and the best practices when modeling requirements as a use case here in this article. That may be for a later day!!

So, what are attributes of requirements?

The BABOK? defines requirements attributes as information about requirements.  Requirements need to be managed during its lifecycle from identification right until it satisfies with a solution to the need for change. The information about requirements often pop-up or must be planned to be captured along with the requirements. These attributes help in effectively and efficiently managing requirements, methodically managing the change and to efficiently managing the stakeholders.

As per the BABOK? there are ten pieces of information to be captured as attributes. They are,

• Complexity – Specifies how difficult it is to implement the requirement. This may be a subjective guesstimate made by the person eliciting and documenting the particular requirement. Complexity may be specified as ‘High’, ‘Medium’, ‘Low’ etc. when writing a use case description
• Absolute Reference – Unique identifier for the requirement. It remains same even if the requirement is moved, changed or deleted. This will be your unique use case ID.
• Risk – These are the severity level of the uncertain events that may impact requirements. Risk may be specified as ‘High’, Medium’, ‘Low’ again in a use case.
• Author – Specifies who wrote the requirement or whom to be consulted if requirement is unclear. This attribute is important as it helps in situations where further clarifications about requirements is required at a latter stage such as during coding or testing. I know we don’t normally specify this in a use case description, but this should become best practice.
• Source – Specifies the origin of the requirement. For example if we are eliciting requirements for a mobile version of a CRM solution for the sales department we may elicit an important requirement from a sales executive on the field. The requirement may be documented in the use case as a scenario and it is important to mention the source so that the stakeholder can be contacted in the future for further clarification.
• Stability – Describes the maturity of the requirement. Specifies whether the team is still in the initial stages of eliciting the requirement, whether elicitation and analysis is complete, whether adequate information has been gathered to ensure that the requirement may not change in the foreseeable future.
• Ownership – This identifies the individual or group that needs the requirement. This may be the business owner / sponsor or even a business division. For example the owners of the CRM mobile solution for which requirements are being elicited can be the Sales Department.
• Urgency – It is important to indicate how soon the requirement is needed so that resources and schedules can be adjusted to implement and deliver the requirement as soon as possible. Urgency of requirements can again be documented as ‘High’, ‘Medium’, and ‘Low’.
• Priority – This indicates the relative importance of a requirement against other requirements. This can again be documented as ‘High’, ‘Medium’, and ‘Low’ and is important to clearly define the business priority against each use case as it will help identify features for the Minimal Viable Product (MVP).
• State – Indicates where the requirement definition stands. In the case of use cases this specifies whether the use case is in draft, reviewed, approved / rejected, implemented state etc.

Lots of information, isn’t it? J. How do we remember these first of all? I use the acronym ‘CARA’S SOUPS’ for this purpose taking the first letter of each requirement attribute.

I would now like to conclude by giving an extended template for a use case description. Why extended? A use case description has a defined set of sections that must be included such as pre-conditions, primary flow, alternate flows, exceptional flows, post-conditions etc. So, given below is the structure I use. You are free to use it or customize it as you deem fit.

We often miss out on these important pieces of information about requirements and get into trouble mid way in projects. Yes, we are now moving in a direction where documentation is considered taboo. You may be practicing Scrum, Kanban, Lean as your project management methodology and you may be adopting design thinking and doing rapid prototyping. Whatever you do my advice is that you make sure to capture requirement attributes for a smoother communication and implementation of requirements.