Chapter 6 – Requirements Modeling: Scenarios and Information

The requirements model is the first technical representation of a system. Requirements modeling process uses a combination of text and diagrams to represent software requirements (data, function, and behavior) in an understandable way. Software engineers build requirements models using requirements elicited from customers. Building analysis models helps to make it easier to uncover requirement inconsistencies and omissions. This chapter covers three perspectives of requirements modeling: scenario-based, data (information), and class-based. Requirements modeling work products must be reviewed for completeness, correctness, and consistency.

 

Requirements Models

• Scenario-based (system from the user’s point of view)
• Data (shows how data are transformed inside the system)
• Class-oriented (defines objects, attributes, and relationships)
• Flow-oriented (shows how data are transformed inside the system)
• Behavioral (show the impact of events on the system states)

 

Requirements Model Objectives

• Describe what the customer requires.
• Establish a basis for the creation of a software design.
• Devise a set of requirements that can be validated once the software is built.

 

Analysis Model Rules of Thumb

• The model should focus on requirements that are visible within the problem or business domain and be written as a relatively high level of abstraction.
• Each element of the analysis model should add to the understanding of the requirements and provide insight into the information domain, function, and behavior of the system.
• Delay consideration of infrastructure and other non-functional models until design.
• Minimize coupling throughout the system.
• Be certain the analysis model provides value to all stakeholders.
• Keep the model as simple as possible.

 

 

 

Domain Analysis

• Umbrella activity involving the Identification, analysis, and specification of common requirements from a specific application domain, typically for reuse in multiple projects
• Object-oriented  domain analysis involves the identification, analysis, and specification of  reusable capabilities within a specific application domain in terms of common objects, classes, subassemblies, and frameworks

 

Requirements Modeling Approaches

• Structured analysis considers data and processes that transform data as separate entities
• Data objects are modeled to define their attributes and relationships
• Process are modeled to show how they transform data as it flows thought the system
• Object-oriented analysis focuses on the definition of classes and the manner in which they collaborate to effect the customer requirements

 

Scenario-Based Modeling

• Makes use of use cases to capture the ways in which end-users will interact with the system
• UML requirements modeling begins with the creation of scenarios in the from of use cases, activity diagrams, and swim lane diagrams

 

Developing Use Cases

• Use cases capture the interactions between actors (i.e. entities that consume or produce information)
• Begin by listing the activities performed by a single actor to accomplish a single function
• Continue this process for each actor and each system function
• Use-cases are written first in narrative form and then mapped to a template if more formality is required
• Each primary scenarios should be reviewed and refined to see if alternative interactions are possible
• Can the actor take some other action at this point?
• Is it possible that the actor will encounter an error condition at some point? If so, what?
• Is it possible that the actor will encounter some other behavior at some point? If so, what?

 

Exceptions

• Describe situations (failures or user choices) that cause the system to exhibit unusual behavior
• Brainstorming should be used to derive a reasonably complete set of exceptions for each use case
•  Are there cases where a validation function occurs for the use case?
• Are there cases where a supporting function (actor) fails to respond appropriately?
• Can poor system performance result in unexpected or improper use actions?
• Handling exceptions may require the creation of additional use cases

 

UML Activity Diagrams

• Supplements use-case by providing graphical representation of the interaction flow within a specific scenario
• Similar to flow chart
• Rounded rectangles used to represent functions
• Diamonds used to represent decision points
• Labeled arrows represent system flow
• Solid horizontal lines indicate parallel activities

 

UML Swimlane Diagrams

• Variation of activity diagrams used show flow of activities in use case as well as indicating which actor has responsibility for activity rectangle actions
• Responsibilities are represented by parallel line segments that divide the diagram vertically headed by the responsible actor

 

Data Objects

• Data object - any person, organization, device, or software product that produces or consumes information
• Attributes - name a data object instance, describe its characteristics, or make reference to another data object
• Relationships - indicate the manner in which data objects are connected to one another

 

 

Class-based  Modeling

• Represents objects system manipulates, operations applied to objects, and collaborations occurring between classes
• Elements of class model include: classes, objects, attributes, operations, CRC models, collaboration diagrams, and packages

 

Identifying Analysis Classes

• Examine the problem statement and try to find nouns that fit the following categories and produce or consume information (i.e. grammatical parse)
• External entities (systems, devices, people)
• Things (e.g. reports, displays, letters, signals)
• Events occurring during system operation
• Roles (e.g. manager, engineer, salesperson)
• Organizational units (e.g. division, group, team)
• Places
• Structures (e.g. sensors, vehicles, computers)

 

Class Selection Criteria

• Consider whether each potential class satisfies one of these criteria as well
• Contains information that should be retained
• Provides needed services
• Contains multiple attributes
• Has common set of attributes that apply to all class instances
• Has common set of operations that apply to all object instances
• Represents external entity that produces or consumes information

 

 

Specifying Class Attributes

• Examine the processing narrative or use-case and select the things that reasonably can belong to each class
• Ask what data items (either composite or elementary) fully define this class in the context of the problem at hand?

 

Defining Operations

• Look at the verbs in the processing narrative and identify operations reasonably belonging to each class that (i.e. grammatical parse)
• manipulate data
• perform computation
• inquire about the state of an object
• monitor object for occurrence of controlling event
• Divide operations into sub-operations as needed
• Also consider communications that need to occur between objects and define operations as needed

 

Class-Responsibility-Collaborator (CRC) Modeling

• Develop a set of index cards that represent the system classes
• One class per card
• Cards are divide into three sections (class name, class responsibilities, class collaborators)
• Once a complete CRC card set is developed it is reviewed examining the usage scenarios

 

Classes

• Entity classes extracted directly from problem statement (things stored in a database and persist throughout application)
• Boundary classes used to create the interface that user sees and interacts with as software is used
• Controller classes manage unit of work from start to finish
• Create or update entity objects
• Instantiate boundary objects
• Complex communication between sets of objects
• Validation of data communicated between actors

 

Allocating Responsibilities to Classes

• Distribute system intelligence evenly
• State each responsibility as generally as possible
• Information and its related behaviors should reside within the same class
• Localize all information about one thing in a single class
• Share responsibilities among related classes when appropriate

 

Collaborations

• Any time a class cannot fulfill a responsibility on its own it needs to interact with another class
• A server object interacts with a client object to fulfill some responsibility

 

Reviewing CRC Models

• Each review participant is given a subset of the CRC cards (collaborating cards must be separated)
• All use-case scenarios and use-case diagrams should be organized into categories
• Review leader chooses a use-case scenario and begins reading it out loud
• Each time a named object is read a token is passed to the reviewer holding the object's card
• When the reviewer receives the token, he or she is asked to describe the responsibilities listed on the card
• The group determines whether one of the responsibilities on the card satisfy the use-case requirement or not
• If the responsibilities and collaborations on the index card cannot accommodate the use-case requirements then modifications need to be made to the card set

 

Associations and Dependencies

• Association - present any time two classes are related to one another in some fashion
• association multiplicity or cardinality can be indicated in a UML class diagram (e.g. 0..1, 1..1, 0.., 1..)
• Dependency – client/server relationship between two classes
• dependency relationships are indicated in class diagrams using stereotype names surrounded by angle brackets (e.g. <<stereotype>>)

 

Analysis Packages

• Categorization is an important part of analysis modeling
• Analysis packages are made up of classes having the same categorization
• In class diagrams visibility of class elements can be indicated using a + (public), - (private), # (package)