SYSTEM REQUIREMENTS CAPTURE

1
COMP 211INTRODUCTION TOSOFTWARE ENGINEERING

• SYSTEM REQUIREMENTS CAPTURE

2
SYSTEM REQUIREMENTS CAPTURE OUTLINE

• System Requirements Capture General
• Life Cycle Role, Artifacts, Workers and Process
• Importance Difficulty
• (Complete) Process
• System Requirements Capture Unified Process
• Domain Modeling
• Use-Case Modeling
• User-interface Description Prototyping
• Acceptance Tests

3
LIFE CYCLE ROLE
Phases
Core Workflows
Requirements
Analysis
Design
Implementation
Testing
iter. n
Iterations
4
SYSTEM REQUIREMENTS CAPTURE

• system requirements capture constructs two main
  models
• domain model describes the applications static
  data requirements
• use-case model describes the applications
  dynamic processing requirements
• the domain model and use-case model are developed
  over several development increments
• inception phase identify most domain model
  elements and use cases in order to delimit the
  system and scope the project (detail the most
  critical use cases (less than 10))
• elaboration phase capture most (80) of the
  remaining requirements
• construction phase capture remaining
  requirements and implement the system
• transition phase no requirements capture unless
  there are changing requirements

5
ARTIFACTS WORKERS
6
ARTIFACTS

• domain model - a model of the persistent classes
  and their associations in the context of the
  system
• use-case model - a model of a system containing
  actors and use cases and their relationships gt
  captures user requirements
• actors - users of the system, outside the system,
  that collaborate with the system gt represents
  the external environment
• glossary - defines important and common terms
  used by analysts and other developers gt also
  called a data dictionary
• domain description - a description of the classes
  and associations in the domain model
• use case description - a description of some
  functionality that the system offers for an actor
  gt a description of a sequence of actions
• user-interface description prototyping - helps
  us to understand and specify the interactions
  between human actors and the system
• architecture description - depicts the
  architecturally significant use cases (5-10)
  those that describe some important and critical
  functionality or the involve some important
  requirement

7
WORKERS

• system analyst - responsible for the whole set of
  requirements delimits system finds classes and
  associations finds actors and use cases
• domain analyst - assists the system analyst in
  specifying detailed descriptions of one or more
  classes and their associations
• architect - describes the architectural view of
  the use-case model
• use-case specifier - assists the system analyst
  in specifying detailed descriptions of one or
  more use cases
• user-interface designer - visually shapes the
  user interface

8
REQUIREMENTS CAPTURE PROCESS
9
IMPORTANCE OF REQUIREMENTS CAPTURE

• Reasons for failure of/problems with software
  development
• incomplete requirements 13.1
• lack of user involvement 12.4
• lack of resources 10.6
• unrealistic expectations 9.9
• lack of executive support 9.3
• changing requirements and specifications 8.7
• lack of planning 8.1
• system no longer needed 7.5

• requirements capture involved in most cases

10
IMPORTANCE OF REQUIREMENTS CAPTURE
cost to find and fix a defect
log scale

• BUT, requirements capture is VERY DIFFICULT!

11
WHY REQUIREMENTS CAPTURE IS DIFFICULT

• our aim is to build the right system
• a system that meets the users needs
• but, users often do not know what they need!
• many types of users
• do not see the big picture
• do not know which aspects of their work can be
  computerized
• requirements capture is often a discovery
  process
• need to get users to understand what we have
  captured and to approve that it meets their needs
• users need to be able to understand our
  specifications
• but, user is usually not a computer specialist!

12
REQUIREMENTS CAPTURE (COMPLETE) PROCESS

• Identify and understand user needs
• define the goals of the system compile list of
  candidate requirements
• define development effort scope compile list of
  system constraints
• Determine feasibility
• economic feasibility operational feasibility
• technical feasibility organizational impact
• Capture and document system requirements
• system context functional and nonfunctional
• (domain model) (use-case model)
• Formulate an acceptance test plan
• criteria for user acceptance of the completed
  system

13
USER NEEDS IDENTIFICATION

• collect data on application domain (may include
  an existing system)
• investigation gt existing documentation
• observation gt work practices
• interviews gt questionnaires, personal
• prototyping gt interface, functions
• distinguish needs from wants importance of needs
• refine system goals, system scope, list of
  requirements, list of constraints, etc.
• document the application domain ? requirements
  specification
• propose scope of computerization

14
USER NEEDS PROBLEMS VS SOLUTIONS

• be careful to elicit problems not solutions!

• Not this We need to put in an East-West
  teleconferencing network.
• This Our East-West offices are not
  communicating in a timely manner.
• Not this We need a dispatching system for our
  trucks.
• This We need to improve the efficiency of our
  use of vehicles in the field.
• software engineering is not a bag of
  solutionslooking for a problem!

15
FEASIBILITY DETERMINATION

• can we/should we build the system?

• economic feasibility
• costs versus benefits
• tangible versus intangible
• technical feasibility
• availability of technology ? risk of new
  technology?
• maintenance required
• operational feasibility
• availability of skills to operate the system
• fit with current work practices
• organizational impact analysis
• politics training user acceptance, . . .

16
DOMAIN MODELING

• captures the most important classes and their
  associations in the context of the system
• things that exist or events in the environment
  of the system

• found from
• high-level problem statement
• lower-level requirements
• domain experts (users)
• classes can be
• business objects (e.g., orders, accounts, etc.)
• real-world objects and concepts (e.g., suppliers,
  customers, etc.)
• events (aircraft arrival/departure, sales,
  reservations, etc.)
• described in a class diagram

17
IDENTIFYING CLASSES ASSOCIATIONS

• naturally occurring things or concepts in the
  application domain
• classes often appear as nouns/noun phrases in
  application domain terminology
• associations often appear as verbs/verb phrases
  in application domain terminology
• Circle or highlight in problem description
• Put all terms into singular form

• relevant classes ? essential throughout the
  systems life cycle
• leads to a stable system

decomposition of a problem into classes and
associations depends on judgement and experience
and the nature of the problem
18
ASU COURSE REGISTRATION PROBLEM STATEMENT

• At the beginning of each semester, students may
  request a course catalog containing a list of
  course offerings needed for the semester.
  Information about each course, such as professor,
  department, and prerequisites are included to
  help students make informed decisions.
• The new system will allow students to select
  four course offerings for the coming semester. In
  addition, each student will indicate two
  alternative choices in case a course offering
  becomes filled or is canceled. No course offering
  will have more than ten students or fewer than
  three students. A course offering with fewer than
  three students will be canceled. Once the
  registration process is completed for a student,
  the registration system sends information to the
  billing system so the student can be billed for
  the semester.
• Professors must be able to access the online
  system to indicate which courses they will be
  teaching, and to see which students signed up for
  their course offerings.
• For each semester, there is a period of time
  that students can change their schedule. Students
  must be able to access the system during this
  time to add or drop courses.

19
DM REFINEMENT KEEPING THE RIGHT CLASSES

• Are any classes redundant?
• Are any classes irrelevant to the application
  domain?
• Are any classes vague (ill-defined)?
• Should any classes really be attributes?
• Do any classes describe an operation?
• Do any class names describe a role?
• Do any classes describe implementation constructs?

20
DM REFINEMENT KEEPING THE RIGHT ASSOCIATIONS

• Are there any associations between eliminated
  classes?
• Are any associations irrelevant to the
  application domain?
• Do any associations describe an operation?
• Can ternary associations be decomposed into
  binary associations?
• Are any associations derived associations?
• Are any associations named with how or why
  names?
• Are role names required for any associations?
• Should any associations be qualified?
• Are multiplicity, ordering specifications
  missing?
• Do any associations describe implementation
  constructs?

21
DM REFINEMENT KEEPING THE RIGHT ATTRIBUTES

• Are attributes closely related to the class they
  are in?
• Should any attributes really be classes?
• Should any attributes be qualifiers?
• Have object identifiers been included as
  attributes?
• Should any attributes be in an association class?

22
DOMAIN MODEL DOCUMENTATION

• for each class we need to identify its attributes
• meaningful name
• short description
• payment - transaction to record remittance
• aliases
• synonyms - same meaning, but different name
• customer client
• acronyms - shortened name
• requisition-number requis-num, reqno
• length - as encountered in the real world
• number of digits or letters

23
DOMAIN MODEL DOCUMENTATION (CONTD)

• allowable values
• continuous - a range of values
• price 0 to 10,000
• need to note range
• typical values
• exception handling
• discrete - only certain values allowed
• marital-status single, married, widowed,
  divorced
• need to note values
• meaning of each (if coded)
• encoding - physical representation of the value
• only if no choice allowed in design phase
• supplementary - other information relevant to use
  of the attribute

24
DOMAIN MODEL DOCUMENTATION (CONTD)

• for each class we can add any operations that we
  are aware of at this stage
• most operations will be added during analysis
  design
• for each association we need to specify (if
  known)
• a name (optional)
• role names (as necessary)
• multiplicity
• association class (if necessary)
• Place all terms and their definitionsin a
  glossary (data dictionary)

25
DM REFINEMENT GENERALIZATION

• classify classes according to similarity of
  attributes and operations
• look for kind-of statements that are true in
  the real world
• do not nest too deeply
• 2-3 levels ? OK
• 4-6 levels ? maybe
• 10 levels ? too deep!
• need to decide how to handle associationsin
  which subclasses participate

26
ASU GENERALIZATION REFINEMENT
What about associations in which subclasses
participate?
27
ASU GENERALIZATION REFINEMENT
Person
CourseOffering

1..10
StudentInfo
ProfessorInfo
?
Person
StudentInfo
ProfessorInfo
1..
3..10
CourseOffering

0..4
28
TOP 10 DOMAIN MODELING ERRORS

• 10. Start assigning multiplicities to
  associations right off the bat. Make sure that
  every association has an explicit multiplicity.
• 9. Do noun and verb analysis so exhaustive that
  you pass out along the way.
• 8. Assign operations to classes without exploring
  use cases and sequence diagrams.
• 7. Optimize your code for reusability before
  making sure youve satisfied the users
  requirements.
• 6. Debate whether to use aggregation or
  composition for each of your part-of
  associations.
• 5. Presume a specific implementation strategy
  without modeling the problem space.
• 4. Use hard-to-understand names for your
  classeslike CPortMgrIntfinstead of intuitively
  obvious ones, such as PortfolioManager.
• 3. Jump directly to implementation constructs
  such as friend relationships and parameterized
  classes.
• 2. Create a one-for0ne mapping between domain
  classes and relational database tables.
• 1. Perform premature patternization, which
  involves building cool solutions, from patterns,
  that have little or no connection to user
  problems.

29
USE-CASE MODELING 7 8

• captures the system behavior from the users
  point of view
• developed in cooperation with the domain model
• helps in
• capturing requirements
• planning iterations of development
• validating the system
• dynamic model gets started with use-case analysis
• drives the entire development effort
• All required functionality is described in the
  use cases

30
USE CASE MODEL ACTORS 7.1 8.2 8.3

• something outside the system that interacts with
  it
• provides input to or takes output from the system
• a role a user can play ? multiple roles per user
  multiple users per role

• actors are the source for discovering use cases
• an actor is a classifier (like a class)
• user is an instance of the classifier
• briefly describe role each actor playswhen
  interacting with the system

31
IDENTIFYING ACTORS

• Who is interested in a certain requirement?
• Where in the organization is the system used?
• Who will benefit from the use of the system?
• Who will supply the system with information, use
  information, and remove information?
• Who will support and maintain the system?
• Does the system use an external resource?
• Does one person play several different roles?
• Do several people play the same role?
• Does the system interact with an existing system?
• Common to have both a domain model classand an
  actor that represent the same thing

32
USE CASE MODEL USE CASE 7.2

• a specific way of using the system by
  performingsome part of the functionality
• constitutes a complete course of events initiated
  by an actor

• initially, we are only concerned with the normal
  or usual course of events
• ignore exceptions, alternate ways of doing
  things
• use case name should be stated from the
  perspective of the user as a present-tense, verb
  phrase in active voice
• provide a description of the purpose of the use
  caseand a high-level definition of its
  functionality

33
IDENTIFYING USE CASES

• What are the tasks of each actor?
• Will any actor create, store, change, remove, or
  read information in the system?
• Will any actor need to inform the system about
  sudden external changes?
• Does any actor need to be informed about certain
  occurrences in the system?
• What use cases will create, store, change,
  remove, or read this information?
• What use cases will support and maintain the
  system?
• Can all functional requirements be performed by
  the use cases?

34
WHAT IS A GOOD USE CASE?

• A use case typically represents a major piece of
  functionality that is complete from beginning to
  end.A use case must deliver something of value
  to an actor.

• Consider students in ASU Course Registration
  System
• select courses
• be added to course offerings
• be billed

deals with one completecourse of events

• Consider Registrar in ASU Course Registration
  System
• add courses
• delete courses
• modify courses

deals with the sameclass of objects
35
USE CASE DOCUMENTATION

• Register for Courses
• Brief Description
• This use case describes the process of how a
  student registers for a course offering. It
  provides the capability to create and modify a
  student schedule for the coming semester.
• Initial Step-by-Step Description
• Before this use case begins, the Maintain Course
  Information use case must execute to create
  course offerings for courses.
• 1. The Student studies the course offerings for a
  semester to determine which courses to select.
• 2. The Student indicates his/her first choice of
  courses, up to a maximum of four.
• 3. The Student indicates his/her alternate choice
  of courses, up to a maximum of two.
• 4. After the registration process for the Student
  is complete, billing information is sent to
  the billing system.

36
USE CASE DOCUMENTATION

• Select Courses to Teach
• Brief Description
• This use case describes how a professor can
  select courses to teach for a desired semester
  that has not started yet.
• Initial Step-by-Step Description
• Before this use case begins, the Maintain Course
  Information use case must execute to create
  course offerings for courses.
• 1. The Professor selects a course offering for a
  semester.
• 2. The Professor either adds or deletes
  himself/herself as the instructor for the course
  offering.

37
UCM REFINEMENT FLOW OF EVENTS

• scenario an instance of a use case
• all scenarios of a use case are attempts to
  carry out the use case
• each scenario is described by a precise, but easy
  to read, description of its flow of events what
  the system should do
• Basic path shows one complete normal path from
  start to end no errors, no exceptions (always
  required).
• Alternative paths show exceptional conditions or
  errors.
• start with basic path, then add alternative
  paths
• Goal account for everything the user might do

38
UCM REFINEMENT FLOW OF EVENTS

• The start state as a precondition
• When and how the use case starts
• Required order of actions the normal sequence
  of events
• What interaction the use case has with the actors
• What data is needed by the use case
• How and when the use case ends
• Possible end states as postconditions
• Paths of execution that are not allowed
• The description of any alternate or exceptional
  flows
• Narrative should be event-response oriented
  (i.e., the system does X when the user does Y)

39
ASU UCM REFINEMENT SELECT COURSES TO TEACH

• Flow of Events for Select Courses to Teach Use
  Case
• Preconditions
• The Create Course Offerings subflow of the
  Maintain Course Information use case must execute
  before this use case begins.
• Basic Path
• 1. The use case begins when the professor logs on
  to the Registration System.
• 2. The professor enters his/her id and password
  and the system verifies that the id and password
  are valid.
• 3. The system prompts the professor to select the
  current semester or a future semester and the
  professor enters the desired semester.
• 4. The system prompts the professor to select the
  desired activity ADD, DELETE, REVIEW, PRINT, or
  QUIT.
• 5. If activity selected is ADD, perform the S-1
  Add a Course Offering subflow.
• 6. If activity selected is DELETE, perform the
  S-2 Delete a Course Offering subflow.
• 7. If activity selected is REVIEW, perform the
  S-3 Review Schedule subflow.
• 8. If activity selected is PRINT, perform the
  S-4 Print a Schedule subflow.
• 9. If activity selected is QUIT, the use case
  ends.

40
ASU UCM REFINEMENT SELECT COURSES TO TEACH

• Subflows
• S-1 Add a Course Offering
• 1. The system displays the course screen
  containing a field for a course offering name
  and number.
• 2. The professor enters the name and number of a
  course. The system displays the course
  offerings for the entered course.
• 3. The professor selects a course offering. The
  system links the professor to the selected
  course offering.
• 4. The use case begins again.
• S-2 Delete a Course Offering
• 1. The system displays the course screen
  containing a field for a course offering name
  and number.
• 2. The professor enters the name and number of a
  course. The system removes the link to the
  professor.
• 3. The use case begins again.

41
ASU UCM REFINEMENT SELECT COURSES TO TEACH

• Subflows (contd)
• S-3 Review a Schedule
• 1. The system retrieves and displays the
  following information for all course
  offerings for which the professor is assigned
  course name, course number, course offering
  number, days of the week, time, and location.
• 2. When the professor indicates that he/she is
  through reviewing, the use case begins again.
• S-4 Print a Schedule
• 1. The system prints the professor schedule..
• 2. The use case begins again.

42
ASU UCM REFINEMENT SELECT COURSES TO TEACH

• Alternative Paths
• A-1 In step 2, an invalid professor id number is
  entered. The user can re-enter a professor id
  number or terminate the use case.
• A-2 In steps 4, 5 and 6, course offerings cannot
  be displayed. The user is informed that this
  option is not available at the current time. The
  use case begins again.
• A-3 In step 4, a link between the professor and
  the course offering cannot be created. The
  information is saved and the system will create
  the link at a later time. The use case continues.

43
UCM REFINEMENT USES 8.1.1

• multiple use cases may share pieces of the same
  functionality
• we can factor out this functionality, place it in
  a separate use case and relate it to all use
  cases that need to use it

ltltusesgtgt
ltltusesgtgt
ltltusesgtgt
44
ASU UCM REFINEMENT SELECT COURSES TO TEACH

• Flow of Events for Select Courses to Teach Use
  Case
• Basic Path
• 1. This use case begins when the professor logs
  on to the Registration System.

• 2. The professor enters his/her id and password
  and the system verifies that the id and password
  are valid.
• 3. The system . . .

2. The Validate User use case is executed. 3. The
system . . .
Flow of Events for Validate User Use Case Basic
Path 1. The use case begins when a user id and
password are entered. The system verifies the
user id and password are valid.
45
UCM REFINEMENT EXTENDS 8.1.3

• specifies how a use case description may be
  inserted into, and thus extend, an existing use
  case

originaluse case

• condition in original use casechecks whether to
  executeextension
• used to show
• optional behavior
• behavior that is only run under certain
  conditions
• several different subflows which may be run based
  on actor selection

ltltextendsgtgt
extensionuse case
46
ASU UCM REFINEMENT SELECT COURSES TO TEACH
Flow of Events for Select Courses to Teach Use
Case Basic Path 1. This use case begins when the
professor logs on to the Registration
System. 2. The Validate User use case is executed.
3. The system prompts the professor to select the
current semester or a future semester and the
professor enters the desired semester. 4. The
system ...
3. The system prompts the professor to select the
current semester or a future semester and the
professor enters the desired semester. If the
semester is invalid, then the Invalid Semester
use case is executed. 4. The system ...

• Flow of Events for Invalid Semester Use Case
• Basic Path
• 1. An invalid semester is entered. The user can
  re-enter the semester or terminate the use case.

• an extension requires a condition to be
  evaluatedto determine whether to execute it

47
NONFUNCTIONAL REQUIREMENTS

• system properties that cannot be expressed as use
  cases, but often place constraints on the use
  cases
• performance (time and throughput) requirements
• reliability requirements
• the environment in which the software is to
  operate
• possible error sources and suitable measures for
  the prevention of such errors and/or the
  minimization of their effect
• constraints on implementation
• life-cycle considerations schedule, budget,
  etc.
• captured as supplementary requirementson use
  cases or system as a whole

48
USE CASES THROUGH THE DEVELOPMENT 7.4

• Planning
• Basis for negotiation with customer as to which
  use cases should be provided in the first release
• Political aspects
• Demonstrate the system doing something valuable
  to the most influential people first
• Technical aspects
• Deliver the highest risk use cases first
• System validation
• walk the use case to see if it can provide the
  required functionality

49
TOP 10 USE-CASE MODELING ERRORS

• 10. Write functional requirements instead of
  usage scenario text.
• 9. Describe attributes and methods rather than
  usage.
• 8. Write the use case too tersely.
• 7. Divorce yourself completely from the user
  interface.
• 6. Avoid explicit names for your boundary
  objects.
• 5. Write using a perspective other than the
  users, in passive voice.
• 4. Describe only user interactions ignore system
  responses.
• 3. Omit text for alternative courses of action.
• 2. Focus on something other than whats inside
  a use case, such as how you get there
  (precondition) or what happens afterward
  (postcondition).
• 1. Spend a month deciding whether to use includes
  or extends.

50
USER-INTERFACE DESCRIPTION PROTPTYPING

• Logical User-interface Design
• specify
• what data (attributes) the user will manipulate
• how they will be represented in the user
  interface
• use cases for each actor will give us the
  attributes

• Physical User-interface Design
• rough sketches (mock-up) of user interface
• prototype user interface for most important actors

51
IDENTIFYING USER INTERFACE ELEMENTS

• Which of the domain classes are suitable as
  user-interface elements for the use case?
• What user-interface elements does the actor work
  with?
• What actions can the actor invoke, and what
  decisions can the actor make?
• What guidance and information does the actor need
  before invoking each action in the use case?
• What information does the actor need to supply to
  the system?
• What information does the system need to supply
  to the actor?
• What are the average values for all input
  parameters?

52
ACCEPTANCE TEST PLAN FORMULATION
tests must be specified that will demonstrate to
the customer that all functions and constraints
of a system are fully operational

• Interface validity
• Do interfaces perform desired functions (accept
  desired input and provide desired output) and
  follow consistent design standards?
• Functional validity
• Does the system provide the required
  functionality and obey the required constraints?
• Information content
• Are the data structures correct (store the right
  data in the required format)?
• Performance
• Does the system meet specified performance
  criteria?

53
ASU ACCEPTANCE TEST PLAN

• Interface validity
• Perform course registration and show that all
  required data for course registration can be
  input.
• Functional validity
• Show that a professor can select a course
  offering to teach.
• Show that a student cannot register for more than
  four courses.
• Information content
• Display a students course schedule and show that
  all required information is shown.
• Performance
• Show the response time to register for a course
  is less than 1 second.
• construct scenarios through which these can be
  demonstrated

54
DERIVING AN ACCEPTANCE TEST PLAN

• restate written requirements in a concise,
  precise and testable way
• group related requirements
• remove any requirements that cannot be tested
• add any additional requirements gathered from
  users
• look at use cases for functional and interface
  requirements
• look at domain model for information content
  requirements
• look at nonfunctional requirements for
  performance requirements
• construct, for each requirement, a test scenario
  that will demonstrate to the customer that the
  requirement is met

55
SUMMARY SYSTEM REQUIREMENTS CAPTURE

• requirements are captured as
• domain model
• use-case model
• user interface description and prototypes
• use cases drive the subsequent iterations
• for each use case we will identify
• matching use-case realizations in analysis model
• matching use-case realizations in design model
• a set of test cases in the test model