Requirements Modeling and Analysis

• Requirements modeling employs text and diagrams for depicting requirements.
• This provides clarity, ease of understanding, and facilitates reviews for correctness, completeness, and consistency.
• A software engineer or analyst constructs these models from stakeholder-provided requirements.
• Requirements models aid in early feedback and serve as the basis for software design.
• It comprises scenario-based, class, and behavioral modeling.
• Work products include use cases for software functions and UML diagrams for system behavior.
• Ensure the models undergo reviews for correctness, completeness, and consistency.

Requirements Analysis

• This specifies software's operational characteristics
• It defines the software's interface with other system elements
• It establishes software constraints
• It elaborates on basic requirements
• It involves inception, elicitation, and negotiation
• It generates scenario-based, class-oriented, behavioral, data, and flow-oriented models.
• These models enable software designers to translate requirements into architectural, interface, and component-level designs.
• The model also facilitates quality assessment after the software is built.

Analysis Focus

• Focus on what needs to be done, not how to do it
• Address user interactions, manipulated objects, system functions, behaviors, defined interfaces, and applicable constraints

Evolutionary Approach

• Requirements specifications may be incomplete initially
• An iterative approach to requirements analysis and modeling is favored

Modeling Requirements

• Should only create the models that will be used by the development team
• Analysis models helps to create the base design for the software increment

Key Objectives

• Describe customer requirements
• Establish a basis for software design
• Define requirements for validation
• Models bridge system-level descriptions of functionality and business functions with software design elements.

Key Qualities

• Model elements must be directly traceable to design model parts.
• There is a division between analysis and design but they can occur together

Rules of Thumb for Analysis Modeling

• Focus on the problem or business domain.
• Keep the abstraction level high.
• Analysis must provide insight into the information domain, function, and software behavior.
• Software architecture and nonfunctional details should be delayed until later.
• Be aware of how software elements interconnect.
• Models should be valuable to stakeholders and simple without sacrificing clarity.

Principles for Requirements Modeling

• The information domain of a problem must be represented and understood.
• Software functions must be defined.
• Software behavior must be represented.
• Models must be partitioned to uncover detail in a layered fashion,
• Move from essential information towards implementation details

Scenario-Based Modeling

• User satisfaction is top priority for computer-based systems
• The software team should properly characterize requirements and build meaningful analysis and design models.
• It begins with use case diagrams, activity diagrams, and sequence diagrams

Actors and User Profiles

• UML actors model entities that interact with a system
• Actors represent human stakeholders or external hardware roles exchanging information with system objects.
• A single physical entity can be portrayed by multiple actors if it takes on different roles for different system functions.
• UML profiles extends existing models to other domains or platforms, allowing revision for Web-based and mobile systems, and viewpoints from different users such as system administrators versus end users.

Creating Use Cases

• User stories summarize stakeholders' perspectives but lack precision, so developers need use cases for clear interaction descriptions.
• A use case defines how an actor uses a system to achieve a goal, capturing interactions between information producers and consumers.
• Inception and elicitation provide information for writing use cases, while requirements gathering identifies stakeholders, scopes, goals, priorities, functional requirements, and manipulated objects.
• To develop use cases, list functions or activities performed by an actor from system functions, conversations, or activity diagrams.
• It can be written in an informal narrative or as an ordered sequence of user actions.

Scenarios

• Use cases of this type are called primary scenarios
• Alternative interaction descriptions gives complete function understanding

Reviewing Scenarios

• Important questions to check include.
• Can the actor can take some other action at this point?
• Is it possible that the actor will encounter some error condition at this point?
• Is it possible that the actor will encounter some other behavior at this point?
• These result in secondary scenarios representing alternative behaviors.

Addressing Error Conditions

• Error conditions can be related to computer-based operation
• Secondary scenarios should be directly related to the action from steps 6 and 7

Alarm Conditions

• Not integrated with current action set
• A secondary scenario for describing alarm conditions occuring can be integrated

Use Case Exceptions

• Situations that represent failures or alternative actions by actors leading to different behaviors

Exception Rationalization

• Is when the system can detect and handle the condition in the exception

Identifying Extensions

• Additional questions for uncovering exceptions include.
• Are there cases in which some “validation function” occurs during this use case?
• Are there cases in which a supporting function (or actor) will fail to respond appropriately?
• Poor system performance can result in unexpected or improper user actions?

Documenting Use Cases

• Informal use cases are sufficient for requirements modeling
• For critical activities, a more formal approach may be desirable when there are many exceptions

Formal Use Cases

• Typical format is:
  • Goal in context: Identifies the overall scope of the use case
  • Precondition: Describes what is known to be true before the use case is initiated
  • Trigger: Identifies the event or condition that "gets the use case started"
  • Scenario: Lists the specific actions required by the actor and appropriate system responses
  • Exceptions: Identifies situations uncovered during use case refinement
• Additional headings included may be self-explanatory

UML use case diagram

• Diagrammatic representation of use case facilitate better understanding by all stakeholders, particularly when the scenario is complex
• It helps relationships within the usage scenario
• Each is represented by an oval.

Class-Based Modeling

• Classes are physical objects that can be easily identified, classified, and defined in terms of attributes and operations
• They are more difficult to comprehend in a software application

Identifying Analysis Classes

• Examine usage scenarios developed as part of the requirements model.
• Perform a grammatical parse on the use cases developed for the system.
• Classes are determined by underlining each noun or noun phrase and entering it into a simple table
• Synonyms should be noted.
• If the class (noun) is required to implement a solution, then it is part of the solution space
• If a class is necessary only to describe a solution, it is part of the problem space.

Analysis Classes

• Manifest in one of the following ways
  • External entities that produce or consume information used by a computer-based system
  • Things that are part of the information domain for the problem
  • Occurrences or events that occur within the context of system operation
  • Roles played by people who interact with the system
  • Organizational units that are relevant to an application
  • Places that establish the context of the problem and the overall function of the system
  • Structures that define a class of objects or related classes of objects.

Selection Characteristics

• Useful for consideration for inclusion to analysis model
  • Retained information: The potential class will be useful during analysis only if information about it must be remembered so that the system can function
  • Needed Services: The potential class must have a set of identifiable operations that can change the value of its attributes in some way
  • Multiple attributes: During requirement analysis, the focus should be on "major” information. A class with a single attribute may, in fact, be useful during design but is probably better represented as an attribute of another class during the analysis activity
  • Common attributes: A set of attributes can be defined for the potential class, and these attributes apply to all instances of the class
  • Common operations: A set of operations can be defined for the potential class, and these operations apply to all instances of the class
  • Essential requirements: External entities that appear in the problem space and produce or consume information essential to the operation of any solution for the system will almost always be defined as classes in the requirements model.

Attributes

• Describes a class that has been selected for inclusion in the analysis model.
• It is the attributes that define the class—that clarify what is meant by the class in the context of the problem space.

Analysis Class Development

• Study each use case and select those “things” that reasonably "belong” to the class
• Answer the question: What data items (composite and/or elementary) fully define this class in the context of the problem at hand?

Operations

• Define the behavior of an object
• They can generally be divided into four broad categories:
  • Operations that manipulate data in some way
  • Operations that perform a computation
  • Operations that inquire about the state of an object
  • Operations that monitor an object for the occurrence of a controlling event
• Functions are accomplished by operating on attributes and/or associations
• An operation must have "knowledge" of the nature of the class attributes and associations

UML Class Models

• Study information and select operations that reasonably belong to the class
• The grammatical parse is again studied, and verbs are isolated
• Some of these verbs will be legitimate operations and can be easily

UML-Relationships

• Expressed as associations that connect to a specific class

CRC (Class-Responsibility-Collaborator) Modeling

• Provides a simple means for identifying and organizing the classes that are relevant to system or product requirements

Model Qualities

- CRC model can be viewed as a collection of index cards
- Each index card contains a list of responsibilities on the left side and the corresponding collaborations that enable the responsibilities to be fulfilled on the right side
- Responsibilities are the attributes and operations that are relevant for the class
- Collaborators are those classes that provide a class with the information needed or action required to complete a responsibility

Implementation Qualities

 - Responsibilities can be one of:
    - Fulfillment by itself, so long as it can not interact or need to interact with another class
    - Collaborated through determination of class collaborations

Model Review Approach

• Participants review through being given a subset of the CRC model index cards
• Review leader leads through use case deliberately
• Holder of the class card is the one asked to describe responsibilities
• The group determines whether the responsibilities satisfies use case
• Modifications can be made if wrong

Functional Modeling

• Addresses two application processing elements
  • User observable elements delivered to the app
  • Operations contained within the analysis classes

Implementation details

• Made through implementing operations within analysis classes

Technical Implementation consideration

• UML activity diagrams for complex functions
• Not so much the complexity of the functions themselves

Behavioral Modeling

• Model to indicated how software will respond to internal or external events or stimuli
• Help provide design guidance for the system being built
• Activity diagrams model system to internal
• State diagrams model system to external

Model Creation

• steps include evaluation, identification, creation, building, and review
• Evaluate all use cases for proper interaction
• Identify events that drive interaction
• Create sequence for use case
• Build state diagram
• Review behavioral model

Identifying Events

• From use case, events occur when the system and actor exchange information

Describing Events

• Identify
  • actor for each event
  • what information is being exchanged
  • Any conditions and constraints

States for model implementation

• Passive: current values of assigned objects
• Active : indicates the status of continuing transformation

Actions (trigger)

• Forces object to make a transition from one state to another

State implementation

UML Diagrams

• A way to represent states and events for classes
• Arrows represent transitions from states
• State models are useful (life history of model), depth of understanding the behavior of the model
• Model event must be specified to show action to be carried out

UML Activity Diagrams

• supplements the use case
• Graphical representation of flow of interaction within scenario
• Engineers can describe activity diagrams as a way of representing system reactions

Activity

can add additional detail that is implcit through use

• Decision diamond

Swimlane

A variation for activity diagram,

• to represent the flow through the use of activities through cases and indicates actors