10 Key Attributes For Describing Software Requirements

/

Requirements attributes are useful for providing additional information about requirements and the level to which they are understood. A comprehensive set of attributes can make the decision-making process more objective for stakeholders and help them in prioritizing requirements. However, many business analysts struggle to decide which requirements attributes are necessary when describing requirements and which can be omitted. In this article, our goal is to provide a starting point when selecting requirements attributes to be defined.

It’s Impossible to Track Everything

The main reason we monitor any data set is because we want to use them to achieve pre-defined objectives. Falling into the trap of monitoring requirements attributes that don’t help us in any way to get to the finish line is a waste of time and effort. Just because we have the means to monitor different requirements attributes does not mean it’s a good idea to monitor them all.

It’s best to select a small number of key attributes and establish a system that allows us to add more requirements attributes as we go along, depending on the nature of the project and which attributes are deemed necessary.

Main Requirements Attributes

Here is a list of some of the most common requirements attributes that can be captured for each requirement:

  1. Unique ID: Each requirement needs to have a unique identification number assigned to it, so that we can easily find it and link it to its business objectives and test cases.
  2. Date Created: Some requirements are identified at the beginning of the project, while others are added later. Knowing when a requirement was created allows us to precisely trace when and where it originated; this can provide valuable information for prioritization and change management.
  3. Current Version: It’s common for a requirement to morph into something completely different as it is analyzed. Unless there is a robust version control system in place, we cannot guarantee that everyone will work with the same version of a requirement. The requirement version number can be used for flagging different versions of the same requirement to prevent confusion.
  4. Requirement Author: Indicates who proposed a requirement.
  5. Assigned To: The ability to gain an indication of who has been assigned which requirement to implement, can facilitate improved balancing of overall workload and lead to increased productivity in the entire team.
  6. Requirements Status: Has the requirement already been implemented or is it just at the stage of proposal? There is no point working on requirements that are yet to be reviewed and approved by key stakeholders.
  7. Priority: Not all requirements are made equal. Some have much higher priority than others, and we should be able to see which ones are the most important and which ones can be deferred to a later release. This attribute provides an indication of which requirement should be implemented first.
  8. Risk: This attribute seeks to answer the following question: What’s at stake if the requirement isn’t implemented? 
  9. Stability: Before we start working on a requirement, we should confirm that it has reached a certain level of stability. Developing software based on requirements that are subject to constant change is not efficient and is far from productive.
  10. Stakeholders: This attribute indicates who will be affected should any changes be made to a requirement.

These attributes can be tracked using software applications as simple as Microsoft Excel or as robust as full-featured requirements management software applications.

Which other requirements attributes do you believe should be on this list?

Image courtesy of Stuart Miles at FreeDigitalPhotos.net