Ch 10: Requirements

CSCI 4320

Requirements Workflow1. Acquire basic understanding of the application

domain (banking, automobile manufacturing)2. Identify Customer Impact3. Identify Constraints (deadlines, costs, existing

hardware, software)

• Written in Language of Client• Problem: Sometimes the client does not know

what is going on in his organization.

GOAL: Assist client in gaining understanding of system

Requirements Workflow

1. Gain an understanding of the application domain (or domain, for short)– The specific environment in which the target product

is to operate

2. Build a business model– Model the client’s business processes– UML Diagrams (use cases)

3. Use the business model to determine the client’s requirements

Iterate the above steps

Understanding the Domain

• Maintain a glossary of technical words used in the domain, together with their meaning

Building a Business Model

• Business Model – Description of business processes of an organization– Banking ( accepting deposits, loaning money,

making investments)

Gathering Information• Interviewing is the Primary Technique

– Open-ended Questions• Encourage person to speak out• Why is your current software unsatisfactory?

– Closed-ended Questions• requires specific answer• How many employees?

– Structured Interview• Preplanned questions, (frequently closed-ended)

– Unstructured Interview• Questions are posted in response to answers received

Gathering Information• Interviewing is not easy

– Interview must be familiar with application domain

– Interviewer must not have already made up his mind regarding client needs

– Listen carefully, suppress preconceived notions

• After interview prepare a written report outlining the results of the interview

• Let interviewee see the report

Gathering Information

• Questionnaire– Many individuals can participate

• Examine Forms In Use– Various fields shed light of importance of

information in use

• Direct Observations– Modern Version :Videotape camera

• Long time to analyze tapes

– Employees may see it as an invasion of privacy

Building A Model

• Model– Set of UML diagrams that represent system

functions

• Use Cases– Model interaction between the software

product and the users of the software (actors)– Show interaction between software product

and the environment– Stick Figures

10.4.3 Use Cases

Example:

Figure 10.1

Identifying Actors

• An actor is a member of the world outside the software product– User– Initiator

• Someone who plays a critical part in the user case

Identifying Actors (cont)

Actors are not necessarily Human. They can be software products.

• When building an E-Commerce Information System you should allow purchasers to pay with credit cards

• Your system interacts with the credit card company information system.

Thus, the credit card company information system is an actor

Identifying Actors (cont)

• Potential Problem– Overlapping Actors– Too Specific

Example:

Don’t prepare different use cases for Physicians and Nurses when one use case for Medical Staff is appropriate.

10.5 Initial Requirements

• The initial requirements are based on the initial business model

• Then they are refined

• The requirements are dynamic — there are frequent changes– Maintain a list of likely requirements, together

with use cases of requirements approved by the client

Initial Requirements (contd)

• There are two categories of requirements• A functional requirement specifies an action that

the software product must be able to perform– Often expressed in terms of inputs and outputs

• A nonfunctional requirement specifies properties of the software product itself, such as – Platform constraints– Response times– Reliability

Initial Requirements (contd)

• Functional requirements are handled as part of the requirements and analysis workflows

• Some nonfunctional requirements have to wait until the design workflow– The detailed information for some

nonfunctional requirements is not available until the requirements and analysis workflows have been completed

Rapid Prototype

• Hastily built software• Exhibits key functionality of the target

product• Omits hidden aspects such as file

updating• Effective when developing user interface• Clients can experiment and give feedback

to developers• Must be built for change

Human Factors

If screens are confusing or product is difficult to use software product will not be used.

•Human Computer Interface (HCI)•User Friendliness

– Ease for humans to communicate with software– Menus– Graphical User Interface (windows, icons, pull-down

menu)

Human Factors (cont)

• Size of letters

• CAPITALIZATION

• Color

• Line length

• Number of lines on screen

Human Factors (cont)

• Limit # of Preceding Menus– Lengthy sequence of menus to reach goal

makes users angry

• Design for different skill levels– Short cuts for advanced – As users become more familiar with product,

streamline screens

• Uniformity of appearance reduces learning time

Reusing the Rapid Prototype

• Discard the prototype – don’t fall into code-and-fix model

• Resulting code of hurriedly put together prototype can be confusing and is difficult to maintain

• Use a different language from that of product

Reusing the Rapid Prototype

• When is it permissible to reuse portions of the rapid prototype?– When CASE tools such as screen generators

and report generators have been used. (Ex. Software Through Pictures Section 5.5, pg 123)

• Management decides BEFORE the rapid prototype is built to reuse portions

• High quality code passes design and code inspections

CASE Tools for the Requirements Workflow

• Drawing tools to draw diagrams

• Documentation can be kept up-to-date

• Weakness– Sometimes CASE Tools are not user friendly– Spend time tweaking layouts

• ArgoUML– Open Source CASE tool for drawing UML

diagrams

Metrics for The Requirements Workflow

• The goal is to rapidly determine client’s needs• How frequently do the requirements change?

– During requirements workflow– During the rest of the software development process

• Who initiated the change? (client, developer)– Client: moving target possibility– Developer: need for revising requirements elicitation

Challenges of the Requirements Workflow

• Wholehearted cooperation of potential users– job security– misleading information

• Negotiation– Persuade client to accept less that what he wants

(compute cost and benefits)– Compromise among managers regarding functionality

• Time for in-depth discussions• Flexibility and Objectivity

– Interviewer should not make assumptions about requirements