Mac,
Re 1. We let projects define their own categories for requirements. However, they are provided with the following as a “starting” point and few have needed to go much further except for some specific technical environment related specializations.
Functional requirements |
Functional |
usage requirement, something the system does |
Validation |
some specific validation that must occur |
Display |
user has an express desire that information is presented (screen or report) in a particular manner |
Data |
business requires that specific data be recorded (persisted) by or through the system |
Supplementary requirements |
Performance |
demonstrable business need that the system response be x at a specific instance |
Constraint |
any requirement that constrains the design of the system in some way. |
Other than the above, I occasionally come across projects that have justifiable needs to add some specific categories on specific projects. For example, they may break constraint up further if the client has specified a zillion design constraints that the project needs to review and justify.
We have deliberately tried to keep the number of categories small while allowing the projects to extend the categories where it will assists rather than hinder the progress.
Re 3. In the main, “large” functional requirements have tended to map to a single use case. In other words, “the system shall provide a function to create a new customer account” pretty obviously maps to “Create Customer Account”. Other use cases arise through normal requirements gathering and analysis work.
We strongly encourage all projects to record business requirements as “external requirements”. These can easily be related to one or more impacted use cases as <<realizations>> and EA takes care of the rest.
Re 2: We encourage projects to adopt the following process for requirements gathering and analyses:
[1]Initially just record the requirement in the top level of either the Functional or Supplementary requirements models.
[2]At frequent group reviews, the EA Type attribute for new/changed requirements is agreed by the project team and set in the model.
[3]As the requirements model matures, suitable “formal” package structuring for the requirements set appears – we do not insists on any specific structure below the model level – the best structure is determined by agreement between the teams responsible for the design, development and support of the specific system.
The structure of the template we provide projects with for using UML is as follows:
| VIEW |
| MODEL |
| | PACKAGE |
| | | SUB-PACKAGE … |
| | | | Diagram |
Specifically, for the system requirements, it is
| REQUIREMENTS view |
| FUNCTIONAL REQUIREMENTS model |
| | (The project determines package structure to suit the system here) |
| SUPPLEMENTARY REQUIREMENTS model |
| SYSTEM CONTEXT model |
| BUSINESS PROCESS model |
| USE CASE model |
| BUSINESS OBJECTS model |
| PRELIMINARY UI model |
| | UI NAVIGATION package |
| | UI DESIGN packages… |
What (all) the above has allowed us to do is to have a fairly consistent approach across all projects in the organization, allow the necessary degree of flexibility for specific projects and, most importantly, comply with the KISS principal.
Projects use the packaging structure below the model level to achieve objectives specific to the system and project. For example, one project that has a large user type or business type base may break up requirements into SME packages thus letting each of the SME’s approve their requirements as a small set rather than presenting them with the tome of all the requirements for the system. Another project, that has cross technology scope (say a Webshere/DB2 based distributed web app) may break up the packages by technology base so their architects and designers are driven by the requirements specific to their technology area. We also encourage the projects to consider running multiple model structures if that will add value. In that scenario, requirements elements are recorded in an agreed “base” structure below the model and other structures re-represent the requirements in a different manner. So a particvular system structure may look something like the following:
| REQUIREMENTS view |
| FUNCTIONAL REQUIREMENTS model |
| | FORMAL REQUIREMENTS (base) sub model |
| | | Structure |
| | REQUIREMENTS BY SME GROUP sub model |
| | | … |
| | REQUIREMENTS BY TECHNICAL LAYER sub model |
| | | … |
| SUPPLEMENTARY REQUIREMENTS model |
| SYSTEM CONTEXT model |
| Etc… |
Bit of a rave, but I hope that gives you some ideas.
Bruce
