The Three Faces of Requirements

When I look back at the lessons from User Stories Applied, I realise that many approaches to requirements muddles different purposes of requirements together. There are three things requirements need to address in one form or another:

  • First, the development team needs an understanding the needs (requirements) of the user.
  • Second, the project needs a specification of what is inside and outside the scope of the project, as well as the priority and status of different deliveries.
  • Lastly, the developers and testers will need to know detailed information about a requirment to implement it correctly.

RUP’s approach to Use Cases, tries to capture all of these aspects of requirements, and fails somewhat in all respects. The User Story approach is different, and I think, better:

  • Understanding the real needs of the system users is defined as outside of the user story approach. I like to call the deliverable fullfilling this role the product description. Mike Cohn, the author of User Stories Applied suggests using User Role Modeling or Interaction Design to document this. I think this is essential. There is a very proficient field of usablity experts out there, but RUP largely ignore this body of knowledge. For understanding the needs of the user, the rule is that less is more. The most important attribute such a description has is that everyone reads it. Thus it needs to be readably. For projects that are subcontracted out however, the description may need more detail. On the other hand, if there is extensive knowledge about the problem domain on the team (Customer on site), the description can be very cursory. In general, one size does not fit all.
  • Specifying and tracking the requirements for the project mandates a manageable requirement list (Crystal Clear). These requirements should obey William Wake’s INVEST guidelines. The main purpose of this list is to control and monitor the project. On most projects the list can be kept fairly agile, but it needs to be well managed at any point in time. With classical user stories, the list is the stack of cards. Use cases often do not pay sufficient attention attention to the Independent, Negotiable, Estimatable, or Small recommendation of the INVEST guidelines. Unless this is kept in mind, Use Cases are not necessarily the right tool for this job. Also remember that on an agile project, items on the requirement list may be split, joined, added, or deleted, even far into the project.
  • When a system requirement is implemented, the team will require a lot of information. “How often”, “how much”, “what format”, “what business rules”? However, and this is important, these requirements are generally not necessary in order to estimate the work reasonably accurately. The information can be extensive, time consuming to gather, and hard to predict up front. In extreme programming, the detailed requirements are discovered incrementally through conversation with the Customer and documented with Acceptance Tests. RUP seems to want to include this information in the up front requirement gathering (Supplementary Specification) which can lead to a very front heavy process.

For a good incremental approach, it is imperative to avoid mixing the detailed system requirements into the other sets of requirements. The reasons for this are:

  • The extra amount of work in the beginning of the project will delay feedback and thus increase risk.
  • Due to the amount of information, having the information be recent in the heads of the people implementing the requirement is a major boon
  • It is almost impossible to get the detailed requirements complete. This leads to a risk of “extra detail being mistakenly associated with extra precision.” (Mike Cohn, User Stories Applied). This is the main reason for the Negotiable guideline for user stories.
  • The extra “weight” of the requirements will make them harder to change, even when changing them would be preferable.
  • The desire to specify all the details in full can very easily lead to “Analysis Paralysis”.

I am just now discovering the separation between these concepts. The separation shows both the need for interaction design/usability as a more extensively used discipline, as well as the danger of confusing the different level of requirements in practices such as use cases.

As a conclusion: If you use Use Cases, especially from RUP, be aware of the different levels of details and make sure to avoid having the initial requirement analysis delay the start of the project too long to provide effective feedback. Develop a sufficient model to understand the needs of all the system stakeholders, create an initial list of deliverable requirements, and get some real feedback.