You can use the following SMART criteria to evaluate functional and non-functional requirements:
Specific - Is the requirement unambiguous, with consistent terminology, simple, and at the appropriate level of detail?
Measurable - Is it possible to verify that this requirement has been met? What tests must be performed, or what criteria must be satisfied to verify that the requirement is met?
Attainable - What is your professional judgment of the technical feasibility of the requirement?
Realistic - Is the requirement realistic, given the resources? Do you have adequate staff? Do you have the skills? Do you have access to the requisite development infrastructure? Do you have access to the required runtime infrastructure? Do you have enough time?
Traceable - Is the requirement linked from its conception through its specification to its subsequent design, implementation, and test?
When in a solution domain, use robustness analysis to categorize your use cases.
You can divide a use case into four kinds of objects using robustness analysis:
Actors - Objects external to use cases. Actors could be human or other external objects such as systems, applications, or devices. Actors interact with the use case by sending or receiving messages.
Boundary objects - The public face of the use case. Actors interact with use cases using boundary objects. The user interface element or the public API of the use case are examples of boundary objects.
Entity objects - The objects with long lives in the use case. Examples of entity objects are purchase order, invoice, and customer.
Controller objects - The glue between boundary elements and entity objects. They contain methods for specific functions in a use case such as Validate user, Create, Retrieve, Update, and Delete (CRUD) functions.
Figure A-1 shows how the use case is divided into objects.
Figure A-1 Use Case Realization
Figure A-2 illustrates the rules of robustness analysis.
Figure A-2 Rules of Robustness Analysis
The rules are as follows:
You can have one or more actors, boundary objects, controllers, and entity objects in a use case.
Actors can only talk to boundary objects.
Boundary objects can only talk to controllers and actors.
Entity objects can only talk to controllers.
Controllers can talk to boundary and entity objects, other controllers, but not to actors.
Note:
Dr. Ivar Jacobson developed the use case and robustness analysis technique. He is well known as the father of use cases and was also one of the authors of the original UML specifications.
