User requirements are determined first. They are written to the SRS and serve as a basis of analysis.
Here we start with a short overview of the application to be developed. Based on this description, more detailed requirements should be developed.
These are high-level requirements of the system which are also called user requirements. After gathering them, an analysis process should be performed in order to develop a deeper understanding of the problem domain. During analysis, basic building blocks of the functionalities are identified and described as system requirements. The main difference between system and user requirements are that while the latter describes exptectations using domain-specific concepts mainly, the former uses computer science terminology. During analysis, domain-specific concepts are "translated" onto a more specific language that various kinds of development team members (architects, programmers, testers, etc.) understand.
A user requirement might be described by several system requirements. An example for that is adding a new product to an existing order: it requires a lookup (or a form-based search) among existing products and the total price of the order should be re-calculated. Different user requirements might result in the same system requirement after analysis like in the case of sending a newsletter and sending a registration confirmation email: from the system's perspective, these two functionalities are quite the same (send an e-mail to a given address), only the text of e-mails will vary.
As it has been noted earlier, Unambiguity. can be achieved by providing a glossary that defines the terms used in the specification. This is extremely important in such cases when some terms have a meaning in the vulgar tongue but we would like to use the same term in a more constraining manner. Using a glossary, terms can be precisely defined and then used in a well-defined and consistent manner throughout the whole documentation os the software. The glossary should be described in Section 1.3 of the SRS (see Figure Recommended structure for SRS documents).
When a need for a new software emerges, the person (or people) responsible for gathering the requirements (based on the size of the software development organization and many other factors they can be business analysts (BA) or system architects) should consult with the future customers or end users of the system. They have imaginations and expectations about how they would like to make use of the system, about how the system should work.
For our case study (as we would like to keep our example simple), we do not have any opportunity to consult with end users, therefore, we will determine what functionalities a real customer would expect. Let us imagine that we are the end users of our software system to be developed. What would our expectations be against such a system? How would we like to use it? What functionalities do we need?
The system of our study is an online book and DVD store. What are the main scenarios that various system users might execute? We (as customers of an online shop) would like to browse among products. For example, the system should present us a list of products. We can scroll up and down and make selections. We would also like to perform various search operations, if we have in idea about one or more attributes or characteristics of the product. If the search result contains too many items, we would like to refine the search. If some more information needed about a certain product, we would like to view its details. If some of the products are fancy to us, we would like to save them to our own bookshelf or, rather, we would like to buy them. We would like to be able to place an order, confirm an order or cancel it. We would like to choose a payment method for the order. We would like to be informed about our pending orders to know when they will be delivered. We would like to receive offers on discounts and be notified on some interesting titles via email. We would like to share our experiences about certain products, or we are curious about the people's opinion on certain items. Last but not least, we would like to give feedback on either the product or the process how we get it.
Now, we have all the customers’ imaginations and expectations in a nutshell. The system, however, will not work without any support. Under such a support, we mean someone who decides about products to be managed and sold by the system, someone who makes decisions about product prices and various kinds of discounts, someone who keeps the customers informed about action offers, someone who maintains products, someone who deals with customer relationship.
Besides customers, we identified two other groups of users from different aspects. One of them is the manager who makes business decisions. The other one is the administrator who should maintain the system itself and also the most important system elements besides customers—namely, the products for sale.
Documenting requirements using UML: use case diagrams
In the UML, use cases capture the requirements of a system (at least, for functional requirements). Use cases are a means of communicating with users and other stakeholders what the system is intended to do. A use case is a kind of behaviored classifier that specifies a complete unit of useful functionality performed by one or more subjects to which the use case applies in collaboration with one or more actors, and which (for complete use cases) yields an observable result that is of some value to those actors (or probably to other stakeholders) of each subject [UML-DIAGRAMS.ORG].
An actor is behaviored classifier which specifies a role played by an external entity that interacts with the system (e.g., by exchanging signals and data), a human user of the designed system, some other system or hardware using services of the system. An actor is always considered to be external to the system.
The term "role" is used informally as some type, group or particular facet of users that require specific services from the subject modeled with associated use cases. When an external entity interacts with the subject, it plays the role of a specific actor. That single physical entity may play several different roles, and a specific role may be played by single or multiple different instances.
All actors must have names according to the assumed role. Examples of actor names (user roles):
Customer
Manager
Shipping System
The standard UML notation for actors is a "stick man" with the name of the actor above or (preferably) below of the icon.
Actors can participate in generalization relationships with other actors. Generalization is rendered as a solid directed line with a large arrowhead (same as for generalization between classes). Actors can also be abstract. The names of abstract actors should be shown in italics. In the followng figure, User is an abstract use case.
Use cases are most frequently identified using a scenario-based requirements elicitation technique (at least, this is true for object-oriented systems). In this context, a use case is a single unit of meaningful work. It provides a high-level view of behavior observable to someone or something outside the system. The notation for a use case is an ellipse.
A use case definition typically includes the following parts:
name and description,
requirements,
constraints, and
scenarios.
Use cases are normally named as a verb phase. It is a good practice to give some name to that unit of functionality performed by a system which provides some observable and useful result to an actor. Example of use case names are: Make purchase, Place order, Manage Account, etc. A brief, informal textual description should also be provided along with the use case.
The requirements define the formal functional requirements that a use case must supply to the end user (or, to be more precise, the actor). A requirement is a contract or promise that the use case will perform an action or provide some value to the system.
These contracts are described by using constraints. Constraints are conditions or restrictions that a use case operates under and include pre-, post- and invariant conditions. A precondition specifies the conditions that need to be met before the use case can proceed. A post-condition is used to document the change in conditions that must be true after the execution of the use case. An invariant condition specifies the conditions that are true throughout the execution of the use case.
A scenario is a formal description of the flow of events that occur during the execution of a use case instance. It defines the specific sequence of events between the system and the external actors. It is normally described in text and corresponds to the textual representation of the sequence diagram.
Use cases can be related to each other. Three basic types of use case relationships are defined: as being a (behaviored) classifier, a generalization relationship can be understood such like between classes—child use case inherits properties and behavior of the parent use case and may override the behavior of the parent. Generalization is rendered as a solid directed line with a large arrowhead, the same as for generalization between any other kinds of classifiers.
Extend is a directed relationship that specifies how and when the behavior defined in usually supplementary (optional) extending use case can be inserted into the behavior defined in the extended use case. An extended use case is meaningful on its own, it is independent of the extending use case. The extending use case typically defines optional behavior that is not necessarily meaningful by itself. The extend relationship is owned by the extending use case. The same extending use case can extend more than one use case, and extending use case may itself be extended. The extension takes place at one or more extension points defined in the extended use case. Extend relationship is shown as a dashed line with an open arrowhead directed from the extending use case to the extended (base) use case. The arrow is labeled with the stereotpye «extend».
An extension point is a feature of a use case which identifies (references) a point in the behavior of the use case where that behavior can be extended by some other (extending) use case, as specified by extend relationship. Extension points may be shown in a compartment of the use case oval symbol under the heading extension points. Each extension point must have a name, unique within a use case. Extension points are shown as a text string according to the syntax:
extension point ::= name [: explanation ]
The optional explanation is some description usually given as informal text (see Figure Figure 2.9, “Sample usage of extension points.”). It could be in other forms, such as the name of a state in a state machine, an activity in an activity diagram, some precondition or postcondition.
Use case include is a directed relationship between two use cases which is used to show that behavior of the included use case (the addition) is inserted into the behavior of the including (the base) use case. The include relationship could be used:
to simplify large use case by splitting it into several use cases,
to extract common parts of the behaviors of two or more use cases.
A large use case could have some behaviors which might be detached into distinct smaller use cases to be included back into the base use case using the UML include relationship. The purpose of this action is modularization of behaviors, making them more manageable.
Figure 2.10. Use cases B and C are extracted from larger use case A into separate use cases ([UML-DIAGRAMS.ORG]).
 |
When two or more use cases have some common behavior, this common part could be extracted into a separate use case to be included back by the use cases with the UML include relationship.
Figure 2.11. Use case C is extracted from use cases A and B to be reused by both use cases using UML include relationship ([UML-DIAGRAMS.ORG]).
 |
Execution of the included use case is analogous to a subroutine call or macro command in programming. All of the behavior of the included use case is executed at a single location in the including use case before execution of the including use case is resumed. Including use case depends on the addition of the included use case, which is required and not optional. Include relationship between use cases is shown by a dashed arrow with an open arrowhead from the including (base) use case to the included (common part) use case. The arrow is labeled with the stereotype «include».
