With increasing frequency, people are coming to us with a common refrain:

“Why do we need text-based requirements?  We all know that, more times than not, the stakeholders don’t know what they want, and this lack of clarity leads to requirements that are often incomplete, incorrect, ambiguous, and constantly changing.  It seems like a waste of time to develop requirements that are going to change anyway!!  Why can’t we use diagrams, use cases, models, or other forms instead?”

It is understandable to not want to waste one’s time writing requirement statements, especially when one knows that they will have to be rewritten in the near future.  But first, let’s look at the factors behind requirement changes, some of which we can control, others we cannot.

The biggest factor for change is there is insufficient time allocated to complete the work necessary to understand the problem, involve stakeholders, and evolve a feasible concept that will result in meeting the stakeholder needs and expectations.  Without the time and resources needed at the beginning of the project, these activities are not done properly.  All too often we jump in and document a set of requirements without spending the time needed to do this upfront work.  In addition, those writing the requirements often don’t understand the importance of requirements nor have been trained how to write well-formed requirement statements.  The result is poorly written requirements that are incorrect, incomplete, conflicting, ambiguous, and constantly changing.

(Note: Read our blog “Why do my requirements keep changing?” for a more detailed discussion on changing requirements.  Read our blog “Requirements – What’s the Big Deal?” to better understand the importance of well-formed requirements and the role requirements play throughout the product development lifecycle.)

Fear of changing requirements is not a reason to abandon text-based requirements!!

As to the alternatives to text-based requirements:

–  Use cases are written in terms of the user’s interaction with the system under development rather in terms of what the system under development needs to do in order for the users to interact in the way they expect to.

–  Use cases, diagrams, and models do not yet cover the wide range of concepts needed such that, as requirements, they do not have the characteristics necessary to clearly communicate stakeholder needs into a language that can be clearly understood by the developers and other stakeholders.

–  Tabular formats have presentational, traceability, and management challenges.

The reality is that textual requirements are useful and needed.  The need for and advantages of textual requirements include:

–  Communication: There is still a very sizeable audience who cannot interpret, or who are not willing to work with, diagrammatic representations of requirements. Text is universal.  Of course, the text has to be written in such a way as to be clear, correct, and unambiguous; but then diagrams can also be unclear, incorrect, and ambiguous if the wrong meaning is assigned to them.

–  Power of expression. There is no limitation on the types of requirements that need to be expressed. The modelling notations of today, diagrams, and use cases tend to focus on the functional architecture and may be capable of expressing functional, performance, and interface requirements but are not presently well suited to expressing requirements dealing with the physical architectural elements associated with quality (-ilities), standards, regulations, and physical characteristics. Textual requirements carry the universal power of expression of natural language.

–  Accessibility: The Systems Engineering tools and modeling languages (UML, SysML, etc.) used to create and view the data and information represented by the model’s dataset are not as available and assessable to all the stakeholders.  Being able to provide requirements in an electronic document format allows the stakeholders to view the requirements in standard office applications.  In addition, there are still managers from the old-school who still prefer and demand printed, text-based documents.

–  Binding Agreement: Text-based requirement statements are more easily understood in an agreement or contract based system development effort by a wider, and often, non-technical set of stakeholders.  A set of requirements represents a binding agreement between the requirement owner and the developers.  To be part of a binding agreement, the requirements must be expressed in a form that has the characteristics of well-formed requirements.  (A complete list of characteristics for well-formed requirement statements and sets of requirements is included in our blog: “INCOSE Guide to Writing Requirements updates made at IW  2015”.)  Currently, no other form, other than textual requirements, has shown to meet these characteristics.

–  System Verification: All product development processes include system verification as a formal process that must occur prior to system acceptance. System verification is defined as the process of providing distinctive evidence that the designed and built system meets the requirements that drove design, coding, and manufacture activities.  Thus, a key characteristic of all well-formed requirements is that they are clear, unambiguous, correct, feasible, and verifiable. Again, no other form, other than textual requirements, has shown to meet these characteristics.

If your organization chooses to use alternate approaches to defining requirements, the characteristics defined in the INCOSE Guide to Writing Requirements are still applicable.  If the alternate form for stating requirements does not have these characteristics, there is a risk that the needs of those for whom the system is being developed will not be met.

As with all our blog posts, your comments on this topic are welcome.

If you have any other questions, feel free to ask your question on our “Ask the Experts” page and we will do our best to provide a timely response.