The phases of requirements analysis and design are discussed in the frame of the Rational Unified Process (RUP) software development process in the next two chapters. RUP is based on the Unified Modelling Language (UML) as an object-oriented graphical modelling language, so the practical examples presented should not be considered general in the practice of other development methodologies [ 3 ] [ 10 ] [ 11 ] [ 12 ] [ 17 ] [ 22 ].
The purpose of requirements discipline in RUP is to definition of the requirement specification capturing the complete functional and non-functional software requirements for the system.
It is important, first of all, to understand the definition and scope of the problem which we are trying to solve with this system. The models developed during Business Modelling can serve as valuable input to this effort. Business modelling helps to understand the structure and the dynamics of the organization in which a system is to be deployed and derive the system requirements needed to support the target organization.
A requirement is defined as a condition or capability to which a system must conform. Requirements management is a systematic approach to finding, documenting, organizing and tracking the changing requirements of a system.
There are many different kinds of requirements. Requirements are usually looked upon as statements of text fitting into one of the following categories:
User requirements. User requirements focus on the needs and goals of the end users. They are statements of what services the system is expected to provide and the constraints under which it must operate.
System requirements. They set out the system’s functions, services and operational constraints in detail.
Software system requirements are often classified as functional and non-functional requirements:
Functional requirements. They specify actions that a system must be able to perform, without taking physical constraints into consideration. Functional requirements thus specify the input and output behaviour of a system.
Non-functional requirements. Many requirements are non-functional, and describe only attributes of the system or attributes of the system environment. They are often categorized as usability, reliability, performance, and substitutability requirements. They are often requirements that specify need of compliance with any legal and regulatory requirements. They can also be design constraints due to the operating system used, the platform environment, compatibility issues, or any application standards that apply.
Domain requirements are a subcategory of requirements. These are requirements that come from the application domain of the system and that reflect characteristics and constraints of that domain. They are formulated by domain-specific terminology. They may be functional or non-functional requirements.
The user requirements are provided by functional requirements. The functional requirements are often best described in a UML use-case model and in use cases. Every functionality of system is modelled by one or more use cases.
The general objectives of the requirements discipline is:
To establish and maintain agreement with the customers and other stakeholders on what the system should do.
To provide system developers with a better understanding of the system requirements.
To define the boundaries of the system.
To provide a basis for planning the technical contents of iterations.
To provide a basis for estimating cost and time to develop the system.
To define a user-interface for the system, focusing on the needs and goals of the users.
In the frame of RUP methodology the activities and artifacts are organized into workflow details as follows:
Analyze the Problem
Understand Stakeholder Needs
Define the System
Manage the Scope of the System
Refine the System Definition
Manage Changing Requirements
Each workflow detail represents a key skill that need to be applied to perform effective requirements management. Analyze the Problem and Understand Stakeholder Needs are focused on during the Inception phase of a project, whereas the emphasis is on Define the System and Refine the System Definition during the Elaboration phase. Manage the Scope of the System and Manage Changing Requirements are done continuously throughout the development project.
The workflow details are listed above in the sequence that is most likely applied to the first iteration of a new project. They are applied continuously in varied order as needed throughout the project.
Problem analysis is done to understand problems, initial stakeholder needs, and propose high-level solutions. It is an act of reasoning and analysis to find "the problem behind the problem". During problem analysis, agreement is gained on the real problems and stakeholders are identified. Also, initial boundaries of the solution and constraints are defined from both technical and business perspectives.
The purpose of this workflow detail is to:
Gain agreement on the problem being solved,
Define the system boundaries, and
Identify constraints imposed on the system.
The first step in any problem analysis is to make sure that all parties involved agree on what is the problem that we are trying to solve with our system. In order to avoid misunderstandings, it is important to agree on common terminology which will be used throughout the project and provide a consistent set of definitions for the system. Early on, we should begin defining our project terms in a glossarywhich will be maintained throughout the project lifecycle.
In order to fully understand the problem, it is very important to identify the stakeholders. Some of these stakeholders, the users of the system, will be represented by actors in our use-case model.
The functionality of a system is defined by different use cases, each of which represents a specific flow of events. The description of a use case defines what happens in the system when the use case is performed. Each use case has a task of its own to perform. The collected use cases constitute all the possible ways of using the system.
To fully understand the system's purpose it must be known who the system is for, that is, who will be using the system. Different user types are represented as actors. An actor defines a role that users of the system can play when interacting with it. An actor instance can be also played by either an individual or an external system. An actor may be anything that exchanges data with the system. The difference between an actor and an individual system user is that an actor represents a particular class of user rather than an actual user. Several users can play the same role, which means they can be one and the same actor. In that case, each user constitutes an instance of the actor.
The principal symbol representing an actor in UML is shown in Figure 7.1.
Finding the actors means the establishing the boundaries of the system, which helps in understanding the purpose and extent of the system. Only those who directly communicate with the system need to be considered as actors. The following set of questions is useful to have in mind when you are identifying actors:
Who will supply, use, or remove information?
Who will use this functionality?
Who is interested in a certain requirement?
Where in the organization is the system used?
Who will support and maintain the system?
What are the system’s external resources?
What other systems will need to interact with this one?
After identifying an actor a brief description of it should be given including information about:
What or who the actor represents.
Why the actor is needed.
What interests the actor has in the system.
Since requirements are things to which the system being built must be conform, it makes sense to find out what the requirements are, write them down, organize them, and track them in the event they change. The requirements management emphasizes the importance of tracking changes to maintain agreements between stakeholders and the project team.
The effective requirements management include maintaining a clear statement of the requirements, along with applicable attributes for each requirement type and traceability to other requirements and other project artifacts. It provides guidance on the requirements artifacts that should be developed, the types of requirements that should be managed for the project, the requirements attributes that should be collected and the requirements traceability that will be used in managing the product requirements.
A Requirements Management Plan specifies the control mechanisms which will be used for measuring, reporting, and controlling changes to the product requirements.
The primary artifact in which we document the problem analysis information is the Vision document, which identifies the high-level user or customer view of the system to be built.
The Vision document provides a complete vision for the software system under development and supports the contract between the funding authority and the development organization. Every project needs a source for capturing the expectations among stakeholders. The vision document is written from the customer’s perspective, focusing on the essential features of the system and acceptable levels of quality. The Vision should include a description of what features will be included. It should also specify operational capacities (volumes, response times, accuracies), user profiles (who will be using the system), and inter-operational interfaces with entities outside the system boundary, where applicable. The Vision document provides the contractual basis for the requirements visible to the stakeholders.
The purpose of this workflow detail is to elicit and collect information from the stakeholders of the project in order to understand what their needs are. The collected stakeholder requests can be regarded as a "wish list" that will be used as primary input to defining the high-level features of our system, as described in the Vision. This activity is mainly performed during iterations in the inception and elaboration phases.
The key activity of this workflow is to elicit stakeholder requests using such input as business rules, enhancement requests, interviews and requirements workshops. The primary outputs are collections of prioritized features and their critical attributes.
This information results in a refinement of the Vision document, as well as a better understanding of the requirements attributes. Another important output is an updated Glossary of terms to facilitate common vocabulary among team members.
Also, during this workflow detail discussion of the functional requirements of the system in terms of its use cases and actors is started. Those non-functional requirements, which do not fit easily into the use-case model, should be documented in the Supplementary Specifications.
In this step, the purpose is to elicit the stakeholder’s needs relating to the project. Examples of stakeholders are investor, shareholder, buyer, designer, documentation writer and so on. The following techniques can be applied to collect and elicit relevant information from the stakeholders:
Brain-storming and idea reduction.
Review of existing requirements.
After finding actors and collecting stakeholder’s needs we have to identify use cases defining the functionality of the system. Use cases are a technique for capturing the functional requirements of a system. A use case describes what happens in the system when an actor interacts with the system to execute the use case, it specifies the behaviour of a system or some subset of a system.
The collected use cases constitute all the possible ways of using the system. Each of use cases represents a specific flow of events. Then Flow of Events of a use case contains the most important information derived from use-case modelling work. It should describe the use case's flow of events clearly enough for an outsider to easily understand it. The flow of events should present what the system does, not how the system is designed to perform the required behaviour.
Use cases are graphically represented as an oval with the name of its functionality written below it (Figure 7.2.).
Following questions can be useful when identifying use cases:
For each actor you have identified, what are the tasks in which the system would be involved?
Does the actor need to be informed about certain occurrences in the system?
Will the actor need to inform the system about sudden, external changes?
Does the system supply the business with the correct behaviour?
Can all features be performed by the use cases you have identified?
What use cases will support and maintain the system?
What information must be modified or created in the system?
Use cases that are often overlooked, since they do not represent what typically are the primary functions of the system, can be of the following kind:
System start and stop.
Maintenance of the system. For example, adding new users and setting up user profiles.
Maintenance of data stored in the system. For example, the system is constructed to work in parallel with a legacy system, and data needs to be synchronized between the two.
Functionality needed to modify behaviour in the system. An example would be functionality for creating new reports.
Similarly to actors the brief description of the use case should be given reflecting its purpose, the actors involved in the use case and the related glossary items.
Diagrams with actors, use cases, and relationships among them are called use-case diagrams and illustrate relationships in the use-case model (Figure 7.3.).
The introduction of notion of requirements types helps separate the different levels of abstraction and purposes of the requirements. Changes to requirements naturally impact the models produced.
Keys to effective requirements management include maintaining a clear statement of the requirements, along with applicable attributes for each requirement type and traceability to other requirements and other project artifacts. A Requirements Management Plan should be developed to specify the information and control mechanisms that will be collected and used for measuring, reporting, and controlling changes to the product requirements. Its purpose is to describe how the project will set up requirements documents and requirement types, and their respective requirement attributes and traceability. Using attributes requirements can be specified more:
It helps the allocation of resources
It helps the effective project monitoring
We can define metrics
We can manage risks
It helps to estimate costs
It helps to manage the Vision
Setting dependencies between requirements provides relations between them and we can keep track how the changes in requirements influence other requirements. Regular reviews, along with updates to the attributes and dependencies, should be done whenever the requirements specifications are updated.
The purpose of this workflow detail is to:
Align the project team in their understanding of the system.
Perform a high-level analysis on the results of collecting stakeholder requests.
Refine the Vision to include the features to include in the system, along with appropriate attributes.
Refine the use-case model, to include outlined use cases.
More formally document the results in models and documents.
Problem Analysis and activities for Understanding Stakeholder Needs create early iterations of key system definitions, including the features defined in the Vision document, a first outline to the use-case model and the Requirements Attributes. In Defining the System you will focus on identifying actorsand use cases more completely, and expand the global non-functional requirements as defined in the Supplementary Specifications. Refining and structuring the use-case model has three main reasons for:
To make the use cases easier to understand.
To partition out common behaviour described within many use cases
To make the use-case model easier to maintain.
An aspect of organizing the use-case model for easier understanding is to group the use cases into packages. A model structured into smaller units is easier to understand. It is easier to show relationships among the model's main parts if they are expressed in terms of packages. The use-case model can be organized as a hierarchy of use-case packages, with "leaves" that are actors or use cases.
A use-case package contains a number of actors, use cases, their relationships, and other packages; thus, there may be a multiple levels of use-case packages. Use-case packages can reflect order, configuration, or delivery units in the finished system. The packages can be organised according the principles:
A package of use cases can be related to a subsystem.
A package of use cases can be related to an actor.
Packages can be formed by any logical grouping.
The objectives of this workflow detail are to:
Prioritize and refine input to the selection of features and requirements that are to be included in the current iteration.
Define the set of use cases (or scenarios) that represent some significant, central functionality.
Define which requirement attributes and traceabilities to maintain.
The scope of a project is defined by the set of requirements allocated to it. Managing project scope, to fit the available resources such as time, people, and money is key to managing successful projects. Managing scope is a continuous activity that requires iterative or incremental development, which breaks project scope into smaller more manageable pieces.
Using requirement attributes, such as priority, effort, and risk, as the basis for negotiating the inclusion of a requirement is a particularly useful technique for managing scope.
Project scope should be managed continuously throughout the project. A better understanding of system functionality is obtained from identifying most actors and use cases. Non-functional requirements, which do not fit in the use-case model, should be documented in the Supplementary Specifications. The values of requirements attributes: priority, effort, cost, risk values etc., are determined from the appropriate stakeholders. These will be used in planning the iterations and identifying the architecturally significant use cases.
The purpose of this workflow detail is to further refine the requirements in order to:
Describe the use case's flow of events in detail.
Detail Supplementary Specifications.
Develop a Software Requirements Specification, if more detail is needed, and
Model and prototype the user interface.
The output of this workflow detail is a more in-depth understanding of system functionality expressed in detailed use cases, revised and detailed Supplementary Specifications, as well as user-interface elements. A formal Software Requirements Specification may be developed, if needed, in addition to the detailed use cases and Supplementary Specifications.
It is important to work closely with users and potential users of the system when modelling and prototyping the user-interface. This may be used to address usability of the system, to help uncover any previously undiscovered requirements and to further refine the requirements definition.
The Requirements Management Plan defines the attributes to be tracked for each type of requirement. The most important attributes are the benefit, the effort to implement, the risk to the development effort, the stability, and architectural impact of each requirement.
Regular reviews, along with updates to the attributes and dependencies, should be done, as shown in the Manage Changing Requirements workflow detail, whenever the requirements specifications are updated.
The functionality of a system is defined by the use cases, each of which represents a specific flow of events. A use case describes what happens in the system when an actor interacts with the system to execute the use case. The use cases describe all the possible ways of using the system. The use case does not define how the system internally performs its tasks in terms of collaborating objects. This is left for the use-case realizations to show.
In an executing system, an instance of a use case corresponds to a specific flow of events that is invoked by an actor and executed as a sequence of events among a set of objects. We call this the realization of the use case. Often, the same objects participate in realizations of more than one use case.
The Flow of Events of a use case contains the most important information derived from use-case modelling work. It should describe the use case's flow of events clearly enough for an outsider to easily understand it. Guidelines for the contents of the flow of events are:
Describe how the use case starts and ends
Describe what data is exchanged between the actor and the use case
Describe the flow of events, not only the functionality. To enforce this, start every action with "When the actor ... "
Describe only the events that belong to the use case, and not what happens in other use cases or outside of the system
Detail the flow of events, all "what" should be answered. Remember that test designers are to use this text to identify test cases.
The two main parts of the flow of events are basic flow of events and alternative flows of events. The basic flow of events should cover what "normally" happens when the use case is performed. The alternative flows of events cover behaviour of optional or exceptional character in relation to the normal behaviour, and also variations of the normal behaviour.
Both the basic flow of events and the alternative flows events should be further structured into steps or sub-flows. A sub-flow should be a segment of behaviour within the use case that has a clear purpose, and is "atomic" in the sense that either all or none of the actions is done.
The purpose of modelling user-interface is to build a model of the user interface that supports the reasoning about, and the enhancement of, its usability. For each use case prioritized to be considered from a usability perspective in the current iteration, we have to take the following steps:
Describing the characteristics of actors related to use case
Creating a use-case storyboard. A use-case storyboard is a logical and conceptual description of how a use case is provided by the user interface, including the interaction required between the actors and the system. The use-case storyboard has various properties, such as text fields and diagrams that describe the usability aspects of the use case.
Describing the flow of events - storyboard. The step-by-step description of each use case that is input to this activity need to be refined and focused on usability issues; this refinement is captured in the Flow of Events - Storyboard property of the use-case storyboard.
Capturing usability requirements on the use-case storyboard
Identification of boundary classes needed by the use-case storyboard. In this step we identify the boundary classes needed to provide the user interface of the use case.
Describe Interactions Between Boundary Objects and Actors. Illustration of the interactions between the participating boundary objects by creating one or more collaboration diagrams. The collaboration diagram should also show interactions between the system and its actors. The flow of events usually begins when one of the actors requests something from the system, since an actor always invokes the use case.
For the identified boundary classes, we have to describe:
Responsibilities of boundary classes
Attributes of boundary classes
Relationships between boundary classes
Usability requirements on boundary classes
The purpose of this workflow detail is to:
Evaluate formally submitted change requests and determine their impact on the existing requirement set.
Structure the use-case model.
Set up appropriate requirements attributes and traceabilities.
Formally verify that the results of the Requirements discipline conform to the customer's view of the system.
Changes to requirements naturally impact the developed models. Identifying the relationships between requirements and other artifacts are the key to understanding the impact of requirements change.
Regular reviews, along with updates to the attributes and dependencies, should be done as shown in this workflow detail whenever the requirements specifications are updated.
There are three main reasons for structuring the use-case model:
To make the use cases easier to understand.
To partition out common behaviour described within many use cases
To make the use-case model easier to maintain.
In order to structure the use cases models, we have three kinds of relationships: the extend and include relationships between use cases and generalization.
Extend relationship between use cases
If there is a part of a base use case that is optional, or not necessary to understand the primary purpose of the use case, it can be factor out to an addition use case in order to simplify the structure of the base use case. The addition is implicitly inserted in the base use case, using the extend-relationship
An extend-relationship is a relationship from an extension use case to a base use case, specifying how the behaviour defined for the extension use case can be inserted into the behaviour defined for the base use case. It is implicitly inserted in the sense that the extension is not shown in the base use case. The extensions can be used for several purposes:
To show that a part of a use case is optional, or potentially optional, system behaviour.
To show that a sub-flow is executed only under certain conditions, such as triggering an alarm.
To show that there may be a set of behaviour segments of which one or several may be inserted at an extension point in a base use case. The behaviour segments that are inserted will depend on the interaction with the actors during the execution of the base use case.
The extension is conditional, which means its execution is dependent on what has happened while executing the base use case. The base use case does not control the conditions for the execution of the extension, the conditions are described within the extend relationship. The extension use case may access and modify attributes of the base use case. The base use case, however, cannot see the extensions and may not access their attributes.
The base use case is implicitly modified by the extensions. We can say that the base use case defines a modular framework into which extensions can be added, but the base does not have any visibility of the specific extensions.
The base use case should be complete in and of itself, meaning that it should be understandable and meaningful without any references to the extensions. However, the base use case is not independent of the extensions, since it cannot be executed without the possibility of following the extensions.
Figure 7.4. shows an example for application of extend relationship.
Include relationship between use cases
If there is a part of a base use case that represents a function of which the use case only depends on the result, not the method used to produce the result it can be factored out to an addition use case. The addition is explicitly inserted in the base use case, using the include-relationship.
An include-relationship is a relationship from a base use case to an inclusion use case, specifying how the behaviour defined for the inclusion use case is explicitly inserted into the behaviour defined for the base use case.
The include-relationship connects a base use case to an inclusion use case. The inclusion use case is always abstract. It describes a behaviour segment that is inserted into a use-case instance that is executing the base use case. The base use case has control of the relationship to the inclusion and can depend on the result of performing the inclusion, but neither the base nor the inclusion may access each other's attributes. The inclusion is in this sense encapsulated, and represents behaviour that can be reused in different base use cases.
Reasons for using the include-relationship are as follows:
Factor out behaviour from the base use case that is not necessary for the understanding of the primary purpose of the use case, only the result of it is important.
Factor out behaviour that is in common for two or more use cases.
The include relationship is shown in Figure 7.5.
If there are use cases that have commonalties in behaviour and structure and similarities in purpose, their common parts can be factored out to a base use case (parent) that is inherited by addition use cases (children). The child use cases can insert new behaviour and modify existing behaviour in the structure they inherit from the parent use case. A generalization is a taxonomic relationship between a more general element and a more specific element. The more specific element is fully consistent with the more general element, and contains additional information.
Many things in real life have common properties. Objects can have common properties as well, which can be clarified using a generalization between their classes. By extracting common properties into classes of their own, it is possible to change and maintain the system more easily in the future.
A generalization shows that one class inherits from another. The inheriting class is called a descendant. The class inherited from is called the ancestor. Inheritance means that the definition of the ancestor including any properties such as attributes, relationships, or operations on its objects is also valid for objects of the descendant. The generalization is drawn from the descendant class to its ancestor class.
A use-case-generalization is a relationship from a child use case to a parent use case, specifying how a child can specialise all behaviour and characteristics described for the parent.
A parent use case may be specialized into one or more child use cases that represent more specific forms of the parent. A child inherits all structure, behaviour, and relationships of the parent. Children of the same parent are all specializations of the parent. This is generalization as applicable to use cases.
Generalization is used when two or more use cases have commonalities in behaviour, structure, and purpose. When this happens, the shared parts can be described in a new, often abstract, use case that is then specialized by child use cases. The representation of use case generalization is shown in Figure 7.6.
An actor-generalization from an actor type (descendant) to another actor type (ancestor) indicates that the descendant inherits the role the ancestor can play in a use case.
A user can play several roles in relation to the system, which means that the user may, in fact, correspond to several actors. To make the model clearer, the user can be represented by one actor who inherits several actors. Each inherited actor represents one of the user's roles relative to the system.
Several actors can play the same role in a particular use case. The shared role is modelled as an actor inherited by the two original actors. This relationship is shown with actor-generalizations. The representation of use case generalization is shown in Figure 7.7.
The purpose is to formally verify that the results of Requirements conform to the customer's view of the system. 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. They can be used for informal review meetings or in daily work.
Normally, the review should be divided into the following meetings:
A review of change requests which impact the existing requirements set.
A review of the entire use-case model.
A review of the use cases, along with their diagrams. If the system is large, break this review into several meetings, possibly one per Use-Case Package or Software Requirements Specification.
What are the requirements?
What are the workflow details of Requirement discipline?
What are the types of requirements?
List some non-functional requirements!
List some stakeholders in a software development project!
Why requirement management is so important?
How use cases can be structured?
What is a scenario?
Explain the main points of workflow detail Manage the Scope of the System!
How generalization and specialisation can be realised?