In Search of Effective Software Requirements

You may be a business executive.

Your organization has business needs that are (or will be) allocated to software. You want to get those needs satisfied as quickly and economically as possible.

You may be an IT executive.

You want your development team to develop the best possible software solution to your customer’s needs—on time and within budget.

You may be a business analyst or software engineer.

You want the software solution to completely and accurately satisfy all its allocated business requirements.

One artifact addresses and supports all these needs—effective software requirements

·      Complete enough to estimate development scope and complexity

·      Specific and itemized enough to enable both development and traceability

·      Accurate and unambiguous enough to enable mutual understanding and verification by all stakeholders (including software developers)

·      A production baseline for alternate solutions and future enhancements

Effective requirement specifications should enable

·      Software product and project management & development

·      Two-way traceability — where is a specific requirement implemented? Which requirements map to this work product?

·      Verification — does a specific software product satisfy its requirements?

·      Change management — if a specific requirement changes, what’s the impact, what rework must happen?

The most typical and least effective form of requirements specification is narrative-text captured in a more or less structured document.

Narrative text fosters inconsistent naming and references, and ambiguity. Aside from oral transmission, narrative text is the least effective form of requirement specification and does little to enable effective verification, management, and development.

The most effective form of requirements specification is a requirements model.

A model can be a document with diagrams and tables in place of structured narrative. A set of computer-assisted analysis tools could capture and relate the same information.

Unlike a narrative-text document, a requirements model enables automated logical proof of requirements, answering verification questions such as:

·      Is every data element defined in the dictionary?

·      Where and how is data used in the system?

·      Can every output data element be mapped to an input element or to a process algorithm that computes it?

·      Does every input have a validation algorithm specified?

·      Is every input data element input actually used by a system process?

·      Is every stored data element that is accessed by any process other than the one that stores it?

·      Is every data element used by a process algorithm

A requirements model is a set of metadata-tables and diagrams that capture

·      System data flows

·      System processes and nested sub-processes with steps and rules (algorithms)

·      System data model

o   Normalized data entities, entity attributes & entity relationships

o   Data dictionary (all entities and entity-attributes)

o   Data storage and storage access by system processes

A computer-assisted requirements model enables

·      Streamlined capture and automated system analysis

·      Data management

·      Formatted analysis reports

·      Data flow analysis

·      Disambiguation, resolution of aliases and duplicates,

·      Requirement traceability

·      Change management

·      Code generation

~

Requirement models can be developed using the unified modeling language (UML) or other machine assisted languages and systems. They can also be developed using facilities as simple as Microsoft Office™ and Visio™ or non-procedural DBMS apps like WebFocus™.

I have personally led development of requirement models using all three approaches.

Occasionally, customer business analysts (with or without support from the development team) create this kind of requirements model in lieu of a narrative-text document.

Sometimes, the development team derives this level of software requirements from the customer’s narrative-text requirements and sometimes this level of specification doesn’t happen at all. Requirement errors, ambiguities, and omissions then emerge as defects and issues in testing or production leading to costly and time-critical rework.

Ideally, the development team would provide automation support and the metadata content would be jointly developed by business and IT analysts. Once developed, the tables and forms would be available for reuse and leveraging by subsequent projects—a baseline model of a baseline production application.

Sometimes this level of software requirements is called a “system analysis” or “requirements analysis”.

Sometimes this level of software requirements is mistakenly called (and confused with) “logical design”. It should precede and enable effective design decisions. It should ideally contain no elements of physical software architecture.

It may seem a “big deal” to develop this level of software requirements. I can attest it is less so than a room of business and IT people sitting glassy eyed around a conference table while wading through reams of narrative-text, spawning defects error and omission that may not surface until testing—or worse until the system is in production operation.

There is probably no business or software process as ripe for qualitative and quantitative improvement as requirements development. Requirements process-improvement is a perfect conjunction of business six-sigma and IT CMM-I initiatives.