Activity: Review Requirements

The following guidelines are helpful when reviewing the results of Requirements:

• Always conduct reviews in a meeting format, although the meeting participants might prepare some reviews on their own.
• Continuously check what is produced to make sure the product quality is as high as possible. Checkpoints are provided for this purpose; refer to the checkpoints for each analysis activity. You can use them for informal review meetings or in daily work.

The following workers, together with the customer and the users, should participate in the review meetings.

• System Analyst
• Use-Case Specifier
• Architect
• Requirements Reviewer

Recommended Review Meetings

Normally, you should divide the review into the following meetings:

• A review of the entire use-case model.
• A review of the use cases (for each use case), along with their diagrams. If the system is large, break this review into several meetings, possibly one per use-case package.

Even if you can review everything at the same meeting, you probably won't get approval of your conclusions the first time. Be prepared to carry out new reviews for each new version of the use-case model.

It is recommended that you arrange one review of the use-case model per iteration in the Inception and Elaboration phases, where you review the work in progress; this is initially done and signed off by the users prior to developing any of the use cases in detail, and is a very important milestone so that resources are not spent on developing incorrect use cases. Then, at the end of the Elaboration phase, you should arrange a detailed review of the use-case model. Remember that at the end of the Elaboration phase, you should have a use-case model, and possibly a domain model representing the glossary, that is 80% complete. You should also arrange one review of the use-case model per iteration in the other phases (Construction and Transition) when the use-case model is refined. The review should concentrate on the part of the use case model being developed for the iteration.

Checkpoints are included in the following sections.

Checkpoints for the Vision Document

• Have you fully explored what the "problem behind the problem" is?
• Is the problem statement correctly formulated?
• Is the list of stakeholders complete and correct?
• Does everyone agree on the definition of the system boundaries?
• If system boundaries have been expressed using actors, have all actors been defined and correctly described?
• Have you sufficiently explored constraints to be put on the system?
• Have you covered all kinds of constraints - for example political, economic, and environmental.
• Have all key features of the system been identified and defined?
• Will the features solve the problems that are identified?
• Are the features consistent with constraints that are identified?

Checkpoints for the Stakeholder Needs Document

• Were the right set of stakeholders involved in producing the document?
• Has the correct set of sources of information been considered?
• Have suitable elicitation techniques been applied when gathering the information presented in the document?
• Does the contents of the document sufficiently cover all areas of interest for the project?

Checkpoints for the Use-Case Model

• Have you found all the use cases? Those you have found must be able to perform all system behaviors; if not, some use cases are missing.
• Do the use cases meet all the functional requirements? If you have intentionally left any requirements to be dealt with in the object models, such as nonfunctional requirements, you must mention this somewhere. If a requirement of this type concerns a specific use case, state this in the Special Requirements section of the use case.
• Does the use-case model contain any superfluous behavior; that is, does it present more functions than were called for in the requirements?
• Does the model actually need all the identified uses-, extends-, and generalization-relationships? If not, they might be redundant and you should probably remove them.
• Do the relationships in the model depend on one another? It is essential that they do not, so you must check this point.
• Is the division of the model into use-case packages appropriate? Does the packaging make the model more simple and intuitive to understand and maintain?
• By studying the use-case model, can you form a clear idea of the system's functions and how they are related?
• Does the Introduction section of the use-case model contain all the necessary information?
• Does the Survey Description of the use-case model contain all the necessary information, for example, does it describe the most common sequences of use cases?

Checkpoints for the Actors

• Have you found all the actors? That is, have you accounted for and modeled all the roles in the system's environment? Although you should check this, you cannot be sure until you have found and described all the use cases.
• Is each actor involved with at least one use case? Remove any actors not mentioned in the use-case descriptions, or any actors without communicates-associations with a use case. However, an actor mentioned in a use-case description is likely to have a communicates-association with that particular use case.
• Can you name at least two people who would be able to perform as a particular actor? If not, check if the role the actor models is part of another role. If so, you should merge the actor with another actor.
• Do any actors play similar roles in relation to the system? If so, you should merge them into a single actor. The communicates-associations and use-case descriptions show how the actors and the system interrelate.
• Do two actors play the same role in relation to a use case? If so, you should use actor-generalizations to model their shared behavior.
• Will a particular actor use the system in several (completely different) ways or does he have several (completely different) purposes for using the use case? If so, you should probably have more than one actor.
• Do the actors have intuitive and descriptive names? Can both users and customers understand the names? It is important that actor names correspond to their roles. If not, change them.

Checkpoints for the Use Cases

• Is each concrete use case involved with at least one actor? If not, something is wrong; a use case that does not interact with an actor is superfluous, and you should remove it. For more information, see Guidelines: Use Case.
• Is each use case independent of the others? If two use cases are always activated in the same sequence, you should probably merge them into one use case.
• Do any use cases have very similar behaviors or flows of events? If so - and if you wish their behavior to be similar in the future - you should merge them into a single use case. This makes it easier to introduce future changes. Note: you must involve the users if you decide to merge use cases, because the users, who interact with the new, merged use case will probably be affected.
• Has part of the flow of events already been modeled as another use case? If so, you can have the new use case use the old one.
• Is some part of the flow of events already part of another use case? If so, you should extract this subflow and have it be used by the use cases in question. Note: you must involve the users if you decide to "reuse" the subflow, because the users of the existing use case will probably be affected.
• Should the flow of events of one use case be inserted into the flow of events of another? If so, you model this with an extends-relationship to the other use case.
• Do the use cases have unique, intuitive, and explanatory names so that they cannot be mixed up at a later stage? If not, you change their names.
• Do customers and users alike understand the names and descriptions of the use cases? Each use-case name must describe the behavior the use case supports.

Checkpoints for the Use-Case Reports

• Does the use case meet all the requirements that obviously govern its performance? You must include any (nonfunctional) requirements to be handled in the object models in the use-case Special Requirements.
• Does the communication sequence between actor and use case conform to the user's expectations?
• Is it clear how and when the use case's flow of events starts and ends?
• Behavior might exist that is activated only when a certain condition is not met. Is there a description of what will happen if a given condition is not met?
• Are any use cases overly complex? If you want your use-case model to be easy to understand, you might have to split up complex use cases.
• Does a use case contain disparate flows of events? If so, it is best to divide it into two or more separate use cases. A use case that contains disparate flows of events will be very difficult to understand and to maintain.
• Is the subflow in a use case modeled accurately?
• Is it clear who wishes to perform a use case? Is the purpose of the use case also clear?
• Are the actor interactions and exchanged information clear?
• Does the brief description give a true picture of the use case?

Checkpoints for the Supplementary Specifications

• Are all requirements listed in the document general, in the sense that none of them should pertain to one single use case?
• Are the requirements correctly categorized?
• Are design constraints correctly specified?

Checkpoints for the Glossary

• Does each term have a clear and concise definition?
• Is each glossary term included somewhere in the use-case descriptions? If not, it may imply that a use case is missing or that the existing use cases are not complete. It is more likely, though, that the term is not included because it is not needed. In that case, you should remove it.
• Are terms used consistently in the brief descriptions of actors and use cases?
• Does a term represent the same thing in all use-case descriptions?

Checkpoints for the Requirements Attributes

• Has the correct set of requirements attributes been used as specified in the Requirements Attributes Guidelines?
• Has all traceabilities been set up as specified for the project in the Requirements Attributes Guidelines?