COMP 325 Lecture 9: Requirements Workflow
major resources: Object-Oriented and Classical Software Engineering 6ed, Schach 2005, Object-Oriented Software Engineering, Schach 2008.

[ previous | schedule | next ]

Overall Goal: Determining what Client Needs

• does not necessarily match what client wants
• client may not be aware of technology solutions
• client is not objective to distinguish between wants and needs
• client may not have big-picture knowledge, or access to it

Requirements Workflow process

1. become familiar with client's application domain
2. build initial business model, using that knowledge
3. determine initial requirements, using business model
4. iterate steps 2 and 3 to refine business model and requirements

Become familiar with client's application domain

• client's application domain is business environment in which software will be used
• easier when one or more analysis team members has experience in that domain
• become familiar with terminology and meanings and distinctions between terms
• build a glossary of application domain terms and their meanings
• this does not necessarily require much interaction with client

Build initial business model

• business model describes business processes
• Brown definition of model: "simplified representation of a complex reality, usually for the purpose of understanding that reality, and having all the features of that reality necessary for the current task or problem." (Introduction to Object-Oriented Analysis Second Edition, David Brown, Wiley 2002)
• Note similarity to definition of abstraction: "focusing on those features that are essential for the task at hand and ignoring those that are not" (same source)
• business model not necessarily limited to process(es) under study for product being developed
• information for business model comes from clients
• client interviews
• may be structured (preplanned set of questions). Some questions should be worded to elicit response beyond yes/no; such responses brings out additional information and possible new avenues to explore
• alternatively, may be unstructured (a couple open-ended questions)
• become familiar with application domain in advance
• listen closely to client responses
• this is where "user stories" are elicited in extreme programming lifecycle model
• write a report afterward and give to client for comment
• questionnaire
• questions must be composed carefully
• usually more structured and closed-ended than interview
• follow-up is not easy and in any case not immediate, so some info can be lost
• no chance to clarify either questions or responses
• can use to get input from large numbers of people
• observe clients
• observe clients go about their business and take notes
• possibly videotape clients for later analysis (privacy concerns)
• examine documents
• forms that are filled out as part of business process
• manuals that the business uses
• operating procedures and job descriptions
• rapid prototypes
• purpose is help client and developer agree quickly on system functionality
• can be employed iteratively
• covered in separate topic below
• Record the business model
• The use case diagram is frequently used
• a use case represents scenario someone could follow to use the system
• identify actors, people who initiate use case
• Note: actors need not be people. They may be other systems which initiate system use (e.g. through a client/server arrangement).
• the drawing is simple
• draw system as rectangle
• draw use cases as ellipses within rectangle
• draw actors as stick figures outside the rectangle
• draw lines from actors to use cases
• Easy for client to follow and understand
• Does not preclude specific analysis/design paradigms
• Does favor OOA; was developed by Jacobson (one of the 3 amigos)
• an alternative is context diagram
• system represented by a rectangle
• external entities (provide or obtain data) represented by rectangle outside the system
• arrow between external entity and system indicates direction of "data flow"
• this technique comes from structured analysis paradigm
• Use Cases are useful for many reasons
  • Understandable by client and developer alike
  • Early measure of system size and scope
  • can locate system "hot spots", risky or complex aspects
  • source of ideas for test cases

Determine initial requirements

• initial requirements are based on initial business model
• if business model specified as use cases, produce written description of each relevant use case
• business model may include use cases outside the scope of the project; leave them as is
• through iteration, business model and requirements descriptions become more detailed
• requirements typically fall into one of two categories
• functional requirement : represents something the system does. Could be described through pre- and post-conditions or descriptions of input and output
• non-functional requirement : represents some constraint the system must meet, usually related to to some quality measure: performance, size, reliability, portability, etc.

Iterate

After recording glossary, initial business model and initial requirements
• submit to client for comment and correction (feedback)
• modify according to feedback
• iterate another round to refine into greater detail
Useful iteration-related metrics for requirements include:
• the number of iterations,
• rate of change across iterations,
• frequency of iterations, and
• requirements changes made later in development

Role of rapid prototyping in requirements workflow

• used to elicit requirements from client through experimentation
• can be used to model key functionality
• can be used to model user interfaces
• the "rapid" is important, must be able to construct and modify quickly
• non-functional requirements such as reliability and performance do not apply
• Should you discard the prototype after requirements determined?
  • Fred Brooks, in chapter 11 of The Mythical Man Month, says "plan to throw one away; you will, anyhow"
  • He sees the choices as these: plan in advance to throw away the prototype, or promise to deliver it to the client
  • one way to assure this is to write the prototype in a different language than the target language
• Visual Studio is convenient for prototyping a traditional WIMP (window, icon, menu, pointing) graphical interface