A Software Engineering Lecture by Steven Choy
Lecture Overview:
In this lecture, we will discuss requirements analysis, the second part of requirement engineering.
During requirements elicitation, initial requirements and the requirements specification were produced. In requirement analysis, developers formalize the requirements specification and examine in more detail boundary conditions and exceptional cases. Developers validate, correct and clarify the requirements specification if any errors or ambiguities are found. Requirements analysis results in a system model that aims to be correct, complete, consistent, and unambiguous.
Reading: Chapter 5 of the textbook Analysis
What you will learn
- The Requirement Process
- Requirement Elicitation (Chapter 4)
- Gather requirement from our users
- Requirement Analysis (this lecture; Textbook Chapter 5)
- Analyze the requirement and build a model for the potential system
Where are we now?
What does requirement elicitation consume and produce?
Requirement Analysis
- Focus on producing a model of the system
- Types of model to produce:
- Functional Model - represented by use cases and scenarios
- Analysis Object Model - represented by class diagrams
- Dynamic Model - represented by sequence diagrams
- The focus of these models should be on user-level, not actual software components/classes for implementation
Who need the Models?
- Is it for user or client?
- Both probably are not interested in object model and class diagrams.
- But by developing object model, you can develop a more thorough understanding of the future system and find out some hidden/ambiguous requirement, which need further clarification.
- Developer
- Aid communication with developers
- Give yourself a big picture
Object Model
- Model the individual concept of the system, their relationships and properties using class and object diagram
- The goal of object modeling is to find classes
Note:
The focus of these models should be at user-level, not implementation level.
That is, the actual software components/classes should not be considered.
Analysis Object Model
Steps for Object Modeling
- Class Identification
- Find the attributes
- Find the methods
- Find the associations between classes
How to find out Classes?
- Not easy if you are lack of experience
- But here are some guidelines to follow:
- Start with use cases
- Scan out the nouns from the "Flow of event" of use cases you developed
- Not all nouns are actual classes - filter those nouns using the filtering rules detailed below
- Abbott Textual Analysis
- Nouns are good candidate of classes
- Verbs are good candidate of operations
- Adjectives are good candidate of attributes
Guidelines on Class Filtering
- Irrelevance
- Redundancy
- Two nouns represent the same thing.
- E.g. credit card, visa card and master card are referring to the same thing
- Analyze those nouns that their primary roles are the same
- An attribute
- Noun that is actually an attribute of a class.
- E.g. credit card number
- An operation
- Noun that actually describes the behaviour of a class.
- E.g. Payment calculation
- An association
- Nouns that describes the relationship between classes
- E.g. A shopping cart contains a list of product items
- "List" is not a class
- An event
- Nouns that describe a time frequency
- E.g. Print payment report every mid-night
- Mid-night should not be a class
- An implementation construct
- Nouns that refer to a hardware
- E.g. Printer, monitor
Mapping nouns to Class - Example
| Part of speech
| Model component
| Examples
|
| Proper noun
| Instance
| Peter
|
| Common noun
| Class
| Customer
|
| Doing verb
| Operation
| Submit payment
|
| Being verb
| Inheritance
| Is a kind of
|
| Having verb
| Aggregation
| Has, consists of
|
Entity, Control & Boundary Objects
Types of Objects
- In OO system, objects are generally grouped into 3 types:
- Entity Objects
- Represent the persistent information of the system (e.g. Player, Customer)
- Boundary Objects
- Serve as a boundary between the actors and the entity objects
- Allow an actor to interact with the system
- Control Objects
- Coordinators of activity in the application domain
Question: Why do we need to categorize objects into these three types?
Answer: Modularity
Let's consider this...
And consider this...
Identify Entity Object
- Use the methodology as described previously to look for classes
- But focus only on those noun phrases that are related to the application domain
Identifying entity objects from a use case of the ARENA
| Use case name
| AnnounceTournament
|
| Flow of events
|
- The LeagueOwner requests the creation of a tournament.
- The system checks if the LeagueOwner has exceeded the number of tournaments in the league or in the arena. If not, the system presents LeagueOwner with a form.
- The LeagueOwner specifies a name, application start and end dates during which Players can apply to the tournament, start and end dates for conducting the tournament, and a maximum number of Players.
- The system asks the LeagueOwner whether an exclusive sponsorship should be sought and, if yes, presents a list of Advertisers who expressed the desire to be exclusive sponsors.
- If the LeagueOwner decides to seek an exclusive sponsor, he selects a subset of the names of the proposed sponsors.
- The system notifies the selected sponsors about the upcoming tournament and the flat fee for exclusive sponsorships.
- The system communicates their answers to the LeagueOwner.
- If there are interested sponsors, the LeagueOwner selects one.
- The system records the name of the exclusive sponsor and charges the flat fee for sponsorships to the Advertiser's account. From now on, all advertisement banners associated with the tournament are provided by the exclusive sponsor.
... ...
|
- Try to apply the "Rules of Class Filtering", find out the real classes
| LeagueOwner
| Tournament
| Number of tournaments
|
| League
| Arena
| Name
|
| Application start and end dates
| Start and end dates
| Maximum number of Players
|
| List of Advertisers
| Exclusive sponsors
| names
|
| Proposed sponsors
| Flat fee
| Answers
|
| Name
| Advertiser's account
| Advertisement banner
|
Potential Classes
ARENA: The Real Entity Objects
| Account
| * Balance, charge history (?), payment history (?)
|
| Advertiser
| * Name, account, sponsored tournament
|
| Advertisement
| * Associated game (?)
|
| Arena
| * max. number of tournaments, flat fee
|
| League
| * max. number of tournaments
|
| LeagueOwner
| * name
|
| Player
| * name
|
| Tournament
| * name, application start date, application end date
|
Identifying Boundary Object
- Boundary objects are NOT explicitly described in use case.
- How do you find out those hidden boundary objects? Ask HOW questions about interface and interaction between actors and the system
- Consider our classic example about Online Shopping system, ask:
- How can customer places a payment order for product purchase?
- How can customer view his/her order history?
- How can the accounting system interface with this system?
- Examples of Boundary Objects for AnnounceTournament use case:
- TournamentForm
- RequestSponsorshipForm
- SponsorshipRequest
- SponsorshipResponse
- Examples of Boundary Objects for BuyProduct use case:
- PaymentForm
- ViewOrderHistoryForm
Identifying Control Objects
- Control objects coordinate activities among boundary and entity objects
- Usually (but not always) a single control object is designed for one particular use case
Example
Identifying Control Objects in ARENA
- Consider AnnounceTournament use case
- We need an object to control activities such as
- Sending and collecting notice to advertisers
- Checking resource availability
- ⇒AnnounceTournamentControl object
Summary: Identifying entity objects
- Entity object: an application domain concept that has information stored in it
- Heuristics for identifying entity objects:
- Terms that developers or users need to clarify in order to understand the use case
- Recurring nouns in the use cases
- Real-world entities that the system needs to track
- Real-world activities that the system needs to track
- Data sources or sinks
Summary: Identifying boundary objects
- Boundary objects: represent the system interface with the actors
- In each use case, each actor interacts with at least one boundary object
- Collect information form the actor and translates it into a form that can be used by both entity and control objects
- Model the user interface at a course level → do not describe visual aspects of the user interface
- Heuristics for identifying boundary objects:
- More on P. 183 of the textbook
Summary: Identifying control objects
- Control objects: responsible for coordinating boundary and entity objects
- Collect information from the boundary objects and dispatch it to entity objects
- Heuristics for identifying control objects:
- Identify one control object per use case
- Identify one control object per actor in the use case
- The life span of a control object should cover the use case or the extent of a user session
Dynamic Model
- Model the operations of the system
- Depicted by sequence diagram and statecharts
|
Recap:
- Sequence diagram represents the interaction among a set of objects, mostly within a single use case.
- Statechart represents the transition of states of a single object.
|
Working out the Model
- How do we produce the dynamic model? How do we get start?
- Start with "Flow of events" of use cases and scenarios
- Review the classes you developed in the Object Model
- Find out the interactions between objects ⇒ Sequence Diagram
- Model the dynamic behaviour of a single object ⇒ Statechart
Working out the Sequence Diagram
Example: ARENA's AnnouceTournament (Tournament Creation)
Example: ARENA's AnnouceTournament (Sponsorship Workflow)
Guideline for drawing Sequence Diagram
- Object Layout
- The first column should correspond to the actor who initiated the use case
- The second column should be a boundary object (that the actor used to initiate the use case)
- The third column should be the control object that manages the rest of the use cases
Requirement Analysis & Dynamic Model
- How does dynamic model aid your requirement process?
- Help you generate questions on some uncertain or ambiguous requirements
- Let developers have a high-level view of how the future system works
Requirement Analysis Document
- The deliverable of both requirement elicitation and requirement analysis processes is a Requirement Analysis Document (RAD)
- RAD documents all the information you gather and develop in the requirement process including:
- Problem statement
- Function/Non-functional Requirement
- Use cases/Scenarios
- Object Model/Dynamic Model
- User Interface - mock up screen
Sample RAD Outline
|
1. Introduction
1.1 Purpose of the system
1.2 Scope of the system
1.3 Project Objectives
1.4 Definition, acronyms and abbreviation
1.5 Overview
2. Proposed System
2.1 Overview
2.2 Functional Requirements
2.3 Non-functional Requirements
2.3.1 Usability
2.3.2 Reliability
2.3.3 Performance
2.3.4 Supportability
3. System Models
3.1 Scenarios
3.2 Use case model
3.3 Object model
3.4 Dynamic model
3.5 User interface - mockup screen
|
Extra materials for your to probe further
Thanks for Reading
If you would rather like to have this lecture note in printed format, please click the print action link in the top right corner.
If you find any problem in this lecture note, please feel free to tell Steven by steven@findaway.hk
