3.1 Requirements Modeling

• What is requirements modeling ?

  A combination of text and diagrams to represent requirements
• Why is requirements modeling important ?

  can be evaluated by all stakeholders for feedback

  Is the basis for software design
• What is requirements analysis ?

  specifics software's operational characteristics

  indicates software's interface with other system elements
• What does requirement analysis allow software engineers to do ?

  elaborate on requirements that were established earlier in requirement engineering tasks

  build models that show the users needs from multiple points of view
• What are the types of requirement models ?

  1. scenario-based
  2. Class-oriented
  3. Behavioral
  4. Data
  5. Flow-orientated
• What are the bridge layers (in order)

  system description, analysis model, design model
• Rules of thumb

  Have a high level of abstraction: requirements that are visible in business, problem domains

  Models should provide insight into information domain, function, and behavior of software

  Delay considering infrastructure and non-functional models until later

  Analysis model provide value to all stakeholders

  Keep the model simple
• Principles of Modeling

  1. The information domain of a problem must be represented and understood.
  2. The functions that the software performs must be defined
  3. The behavior of the software (because of external events) must be represented.
  4. The models that show information, function, and behavior must be divided in a manner that uncovers detail in a layered (or hierarchical) way.
  5. T he analysis task should move from essential information toward implementation detail.
• Scenario-based Modeling: Actors and Profiles

  UML Actor: models an entity that interacts with a system object. Could be roles played by human stakeholders or external hardware as they interact with system objects by exchanging information.

  UML Profile: gives a way to extend an existing model to other domains or platforms. Can be used to model the system from the points of view of different users.
• Use case is a "contract for behavior" and more formal than a user story
• Use cases help define what exists outside the system (actors) and what should be performed by the system (use cases)
• To write a set of use cases, list the functions or activities performed by a specific actor
• Information from inception and elicitation is used to write use cases
• Functions or activities performed by a specific actor can be obtained from a list of required system functions, conversations with stakeholders, or evaluation of activity diagrams developed as part of requirements modeling
• Use cases of this type are sometimes called primary scenarios
• Alternative interactions

  Helps to understand a function described by the use case.

  Secondary scenarios represent alternate use case behavior
• Defining exceptions

  Is a situation (either a failure condition or an alternative chosen by the actor) that causes the system to exhibit somewhat different behavior.
• Defining exception Questions

  Are there cases in which some “validation function” occurs during this use case?

  Can poor system performance result in unexpected or improper user actions?

  Are there cases in which a supporting function (or actor) will fail to respond appropriately?
• Use Cases: Things to avoid

  Single messages are not use cases: use cases represent large number of different scenarios that can have hundreds of messages.

  Low level interfaces are not use cases

  LL's are a way to realize use cases

  Use cases need to map to a reason for the user to interact with the system
• Requirements and Use Case Models

  Use case models do not provide atomized requirements statements.

  They can be traced to requirements by a traceability matrix and a defined schema

  Data and non-functional requirements are not explicit

  Use case models sometime serve as surrogates for requirements
• What do class based models represent ?

  objects that the system will manipulate

  operations or methods or services that will be applied to the objects to effect the manipulation

  relationships between the objects

  Defined collaborations that occur between the classes.
• Elements of a class model:

  • classes and objects
  • attributes
  • operations
  • CRC models
  • UML Class diagrams
• Identifying Analysis Classes

  • Examining the usage scenarios developed as part of the requirements model and perform a "grammatical parse“.
  • To determine classes: underline each noun or noun phrase and enter it into a simple table
  • Note down synonyms
  • If the class (noun) is required to implement a solution, then it is part of the solution space
  • If a class is needed to only to describe a solution, then it is part of the problem space
• Analysis classes: What to do after all nouns are isolated ?

  • External entities: (systems, devices, people) that produce/ consume information.
  • Things: (reports, displays, letters, signals) that are part of the information domain.
  • Occurrences: that occur in 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 overall function.
  • Structures: (sensors, four-wheeled vehicles, or computers) that define a class of objects or related classes of objects
• Selecting Analysis Classes:

  • Retained information: class is useful only if information about it must be remembered
  • Needed services: class must have operations that can change its attributes in some way
  • Multiple attributes: Focus on "major" information;
  • Common attributes: attributes defined for a class that apply to all instances of the class.
  • Common operations: operations defined for the class that apply to all instances of the class
• • Essential requirements: External entities in the problem space that produce/consume information essential to the solution will usually be defined as analysis classes in the model.
• • Attributes describe a class that is included in the analysis model.
  • Attributes that define the class clarify what the class means in the problem space.
  • Meaningful attributes come from looking at use cases and picking " things " that " belong " to the class.
  • What data items(composite / elementary) define this class in the problem?
• Operations: Defining operations

  • They define the behavior of objects
  • Are divided into 4 categories: data manipulation, preform computation, inquire about state, monitor object for a controlling event
  • an operation must have “ knowledge ” of the class attributes and associations.
• Class Responsibility Collaborator (CRC)

  helps identify and organize classes. It is usually a collection of index cards that represent classes.

  Each card is divided into 3 sections: name of the class which is at the top, class responsibilities (left), collaborators (right).
• CRC Model Review Process

  1. All stakeholders get a subset of CRC cards. No one should get cards that collaborate.
  2. The leader will read the use case. When they come to a named object; pass a token to the person holding the matching CRC card.
  3. The person with the token describes the responsibilities on their card. The group decides if a responsibility satisfies the use case requirement.
  4. If theres an error; modify the card
• Functional Modeling

  • 2 Addresses application elements: user-observable functions that is delivered by the app to end users. operations within analysis classes that implement behaviors associated with the class.
  • UML Activity Diagrams show processing details
  • UML Activity Diagrams replace use case by showing visual of the flow interaction
• Behavioral Modeling: sequence diagram

  • UML Sequence can model behavior
  • Once events have been identified from a use case, the modeler creates a sequence diagram—a representation of how events cause flow from one object to another as a function of time.
  • A shorthand version of a use case
• Behavioral Modeling

  • indicates how software will respond to internal or external events. Useful info to create a design to build the system
  • UML activity diagrams: model how system elements respond to internal events.
  • UML state diagrams: model how system elements respond to external events.
• Creating Behavioral Models:

  • Evaluate use cases for the sequence of interaction in the system.
  • Identify events that drive the interaction sequence and understand how these events relate to specific objects.
  • Create a sequence diagram for each use case.
  • Build a state diagram for the system.
  • Review the behavioral model for accuracy and consistency.
• Identifying Events:

  • A use case is a sequence of activities that involves actors and the system
  • An event occurs whenever the system and an actor exchange information.
  • An event is the fact that info was exchanged
  • Look at use cases to find points of info exchange
  • Events trigger state transitions.
• Swimlane Diagram

  • This UML diagram is a useful version of the activity diagram that lets you represent the flow of activities described by the use case
  • Swimlane diagrams indicate which actor or analysis class is responsible for the action described by an activity rectangle
  • Responsibilities are represented as parallel like the lanes in a swimming pool