Organizing Requirements

What is...O Oct 18, 2018 5 mins 27018 Views 0 Comments 0 Likes

The voluminous amounts of information that an analyst collects during the discovery and elicitation phases warrant a good deal of planning and organization in order to make business or user requirements into a usable, cohesive whole. As with any other organization process, the key element to requirements’ organization success is thorough preparation and planning.

What are the criteria for organized requirements?

According to BABOK 2.0, an analyst has two main objectives when organizing requirements: (1) to understand which models are appropriate to include based on the business need, and (2) to understand and clearly communicate the interdependencies and relationships between the various requirements.¹ Whatever model an analyst determines to be appropriate, it must be consistent with established models the rest of her department is using. Standards will enable an analyst to present a cohesive, easily understandable system and structure to stakeholders. Additionally, an analyst must execute a method that will illuminate requirements prioritization and inter-relationships. This will enable her to organize requirements for the project at hand.

Establishing requirements organization standards

To quote BABOK, strong requirements will “follow organizational standards [that] will be used consistently on projects. If no standard exists, the business analyst must select an appropriate set of techniques.”² Therefore, if standards have not been thoroughly documented, together with her colleagues, an analyst should create them. The following preliminary steps are helpful when organizing requirements for a department or organization.

Institute a standard reference system. A type of unique identifier for each requirement, whether through Roman numerals or some other method, must be established. Many requirements software programs include this feature. According to the Requirements Authority, “Requirement reference numbers will assist in aligning future development artifacts (functional designs, modules, test scripts, etc.) to the original requirements.”³ It is important that analysts not use the automatic numbering systems that many word processing programs offer, since any edits or additions will cause the requirements to re-number or re-organize, rendering unique identification moot. A requirement that has the identifier RE1 must remain RE1 throughout all project iterations and requirements revision to ensure traceability. In addition to unique identifiers, an analyst may find it helpful to attach metadata to each requirement in order to make it more relevant to stakeholders. This may be done at the level of organizational standards, or it may be done on a project by project basis, as appropriate. (This is explored more thoroughly in point 6 of the Organizing Requirements for the Project at Hand section.)
Institute standard layouts and models. Also, a group of analysts must designate models and standard layouts for requirements documents, i.e., whether risks and constraints will be listed in a section at the beginning or the end, whether references will be included in footnotes or end notes, and so on. This establishes document style and stakeholder expectations for what each requirements document will include. In addition to using a standard manual layout or model, many organizations find requirements management tools helpful in organizing requirements, offering a systematic way to quickly arrange and categorize the elements within a document. However, Karl Wiegers, author of More About Software Requirements, notes, “These are requirements management tools, not requirements development tools—you still have to write strong requirements.”⁴ Helping to organize and track requirements is only one component of a good requirements management system, but a key one.

Once the analysts have determined the best identifiers, models, and layout methods for their particular organization, a well-organized requirements template can be established and posted on an internal server for all analysts to use.

Organizing Requirements for the Project at Hand

The following steps are helpful when organizing requirements for a specific project.

Implement a method or technique that will reveal the requirements’ prioritization and cross-relationships. This must be clear in an analyst’s mind before a requirements document can be created coherently. BABOK notes that a characteristic of successful requirements is to “document dependencies and interrelationships among requirements.”⁵ Further, according to Chad La Fournie of the Software Engineering Research Network, prior to creating any requirements document, an analyst must devote some time to putting requirements in order prior to documenting them, whether on a system as elemental as laying out index cards with written requirements or as sophisticated as creating a type of matrix. “As humans most of us cannot visualize the relationships between the many requirements (especially if the system is large) in our head. Organizing them and prioritizing them creates a structure showing the relationships between requirements, whether is hierarchical, shows a relationship, or shows conflict.”⁶ The chosen method of preliminary requirements organization may be conducted in concert with key stakeholders to ensure that everyone is in agreement. Once the analyst has laid out the requirements hierarchies and inter-relationships, she can move forward with documenting them.
Write the summary and scope. A textual user or business requirements document should always begin with the project summary. If a separate scope document has not been created, the project’s scope should be at the beginning of the document following the summary.
Advise stakeholders of project roadblocks. Constraints, risks, and the like must be outlined in the document. The aforementioned requirements prioritization/inter-relationship technique that the analyst employs will be useful in helping her to identify these.
Systematically list project features. Generally working from broad to specific, an analyst should begin with more general requirements, i.e., “We will create a delivery system that will meet the business needs of our customers.” Details about each broad requirement should be offered as sub-points of the more general point, or further within the requirements document. Therefore, an analyst must first determine what the “big-picture” requirements are, and working from there, cite a thorough list of specifics about each one. This is essential to requirements organization, particularly for larger projects. While it may become easy to become overwhelmed at this stage, particularly for larger projects, an analyst must remember to focus on the project and the business need to help her move from general to specific. As an IIBA presentation aptly notes, “Don’t agonize, organize.”⁷
Organize requirements in a way that makes them as user-friendly as possible for all stakeholders. One requirements organization pattern is unlikely to work perfectly for all stakeholders. To that end, requirements should be organized and labeled in a way that makes them flexible, enabling one person or department to quickly find what is relevant to their work. For example, all requirements related to data or data sources might be labeled so in order to assist the data base analysts; all requirements related to regulations might be labeled so to assist the legal department; all requirements related to UI design or usability might be labeled so to assist the graphic designers and marketing departments, and so on. Along these same lines, it may be useful to define relevant metadata for each requirement in order to enable stakeholders to sort and filter requirements based on their needs. Examples of possibly relevant metadata attributes that may help in organizing requirements include priority, cost, data source(s), release date(s), risk, corresponding systems, whether or not the requirement will be customer-facing, and so on.
Many analysts may find it useful to label requirements by requirements type. For example, a given requirements document may be divided into functional and non-functional requirements, customer-facing and non-customer-facing requirements, and so on. These requirements can be further sub-divided, if useful. Non-functional requirements, for example, may be broken down into performance requirements, regulatory requirements, or business requirements. Customer-facing requirements may be further organized into UI requirements, performance requirements, and so on.?
List references and appendices. References and appendices, or links to them, are normally incorporated at the end of an organized requirements document.

A Sample Template for Organizing User or Business Requirements

To summarize, the following is an idea of the structure for sections, listed in order of inclusion, that may reside in an organized requirements document. As with all things related to business analysis, this must be tailored to an analyst’s organizational and individual project needs. The exact template is not as important as establishing departmental consistency to ensure requirements organization.

Summary, stating the project’s business need and proposed solution.
Scope, stating the limits of the project (if not already established in separate scope document).
Success Criteria, if your organization employs these. If included, these must have unique identifiers to enable traceability, i.e., “SC1: Delivery costs will decrease by 40 percent within two years.”
Risks, Limitations, Dependencies and Constraints. These also must have unique identifiers to enable traceability, i.e., “DE1: The virtual server update must be completed before this project may be implemented.”
Project Features, with reference points and organized from broad points to specific sub-points.
Glossary, if included. This would include project-specific verbiage with which stakeholders may not be familiar.
References and Appendices, with links to previous scope documents, requirements iterations, graphs, or other related documents.