Yes

bracechumpInternet and Web Development

Feb 5, 2013 (4 years and 6 months ago)

126 views

Requirements Engineering
Processes

Based on
chp
.
7
of
Sommerville

6

CMPT 275, Summer 2009

Toby Donaldson

Overview


Feasibility studies


Elicitation and analysis


Validation Management

2

Donaldson/275

Requirements Engineering


Goal: create an maintain a requirements
document


This involves 4 main steps

1.
Determine if the system is useful

2.
Get the requirements

3.
Putting requirements into a standard format

4.
Validating them


Donaldson/275

3

Requirements Engineering

Donaldson/275

4

Feasibility
study

Requirements
elicitation and
analysis

Requirements
specification

Requirements
validation

Feasibility
report

System
models

User & system
requirements

Requirements
document

This is very
traditional waterfall
-
like approach.

Requirements Engineering

Donaldson/275

5

Feasibility
study

Requirements
elicitation and
analysis

Requirements
specification

Requirements
validation

Feasibility
report

System
models

User & system
requirements

Requirements
document

A more incremental
“spiral” approached
is given in Figure
7.2 of the textbook.

Feasibility Studies

Donaldson/275

6


These are short studies that try to answer
these questions

1.
Does the system contribute to the overall
objectives of the organization?

2.
Do we have the time, money, and know
-
how to
implement the system?

3.
Can the system be integrated with existing
systems?

Feasibility Studies

Donaldson/275

7



During such a study, questions like these may be
helpful


What would happen if the system were not
implemented?


What are the current problems that a new system
would solve?


What are the direct contributions of the system?


Can it share information with existing systems?


Does it use technology new to the organization?


What are the support issues for the system?

Example: A New CS GradeBook?

Donaldson/275

8


The current CS GradeBook is about 15 years old


It works, but has a few issues


The codebase is old and messy, making most changes
very

difficult


The look
-
and
-
feel of the site is quite old
-
fashioned
(built before the age of CSS!)


No show
-
stopping flaws, but lots of little complaints
from students and teachers, e.g.


GradeBook nowhere tells you the # of people in a course!


Can’t change the marking scheme


Idea: Write a new GradeBook using
Django


Django

is a popular Python
-
based web
framework


Like Ruby on Rails, but using Python instead of
Ruby


Would probably take only a couple of weeks
to get a more
-
or
-
less equivalent version up
and running


Would automatically be more modular


Uses CSS


Django

is inherently modular


Donaldson/275

9

But is it Feasible?

1.
Does the system contribute to the overall
objectives of the organization?


Yes
: storing and communicating grades is
fundamental

2.
Do we have the time, money, and know
-
how to
implement the system?


Yes to time and know
-
how; as for money, probably
not

3.
Can the system be integrated with existing
systems?


Yes


Donaldson/275

10

But is it feasible?

Donaldson/275

11


What would happen if the system were not implemented?


We’d continue use the current GradeBook


What are the current problems that a new system would solve?


Fixes the codebase, interface, and architecture of the current system


What are the direct contributions of the system?


Can it share information with existing systems?


Yes; however, it would probably require transferring data from the old
GradeBook database to a new one


Does it use technology new to the organization?


Yes:
Django

has not been used extensively in CS department


What are the support issues for the system?


Same as the current GradeBook

Recommendation


This is not so simple


The current GradeBook works fine, and has some
flaws that we can live with


Unclear how easy/difficult it is for new
sysadmins

to
learn


A more cleanly
-
designed system would be easier to
learn and maintain


The effort to create, debug, test, and maintain a
new system is non
-
trivial


Current budgets are not big!

Donaldson/275

12

Recommendation


More information is needed to make a good
decision


What are the issues from the students point of view?


How difficult will it be to get working with the current
assignment submit tool (will that have to be re
-
written too)?


Is the department planning to move to a new website
using other technology


May want to coordinate moves, or “buy” what we need in a
move to new web system

Donaldson/275

13

Recommendation


We haven’t made a decision!


Well, we did say what other information we want to
get


If we had to make a decision based on the current
information, I’d say:
NO


The current GradeBook has warts, but it works


Building a new system and getting to the same level of
reliability and quality will take significant time and
money


We can re
-
visit this decision later as we learn more

Donaldson/275

14

Requirements Elicitation & Analysis


Work with stakeholders to determine what the
system should do, and what the constraints on it
are


Stakeholders are anyone with an interest in the
system


End
-
users


Managers


Sysadmins


Developers


Trade union reps


Etc.

Donaldson/275

15

Eliciting Requirements


Usually tough because


Stakeholders may


not know what they want in a system


find it hard to articulate what they want


make unrealistic requests


Stakeholders often speak in domain
-
specific language that
developers might not understand


Different stakeholders have different requirements that
they may state in different ways


Politics may interfere


Business environment changes rapidly: resources may
appear/disappear; requirements may need to be amended

Donaldson/275

16

An Iterative Process

1.
Discover requirements

2.
Classify and organize them

3.
Prioritize them


May involve negotiation with stakeholders

4.
Document them

Repeat as necessary

Donaldson/275

17

Requirements Discovery


Gather requirements from stakeholders


Many ways to do this


Guess


Interviews


Observation


Viewpoints


Prototypes

Donaldson/275

18

Guessing


You could just guess what users want based on “common
knowledge”


Common in practice because it is cheap and quick


Plus many developers have a strong feeling about what is right
and wrong when it comes to software


Works great if you guess right, but


When you guess wrong you look bad


Often a gap between what you think you will like, and what you
actually like


What seems important to you as a software developers may not
be so important to real users


E.g. software developers often have more interest/tolerance in highly
technical things than “regular users” who don’t care about keyboard
shortcuts, data structures, file systems, etc.


Donaldson/275

19

Viewpoints


A technique for classifying stakeholders and
requirement sources


Three general types of viewpoints


Interactor


E.g. in a GradeBook, these would be students, teachers, the
GradeBook database, and the GradeBook website


Indirect


E.g. in a GradeBook, these would be non
-
users who have an
interest in the system, such as department chairs (who approve
grades), course advisors,
sysadmins


Domain


E.g. in a GradeBook, these would be domain constraints such as
the need to calculate letter grades, keep student data private, etc.

Donaldson/275

20

More Specific Viewpoints


Providers and receivers of services


Systems that interface with the proposed
system


Developer viewpoints


Developers may be able to suggest requirements
that simplify the system maintenance


Marketer viewpoints


Important for products you plan to market


Important for many web systems


Donaldson/275

21

GradeBook ViewPoints

Viewpoints

Indirect

goSFU

(SIMS)

CMPT
Website

Submit
Tool

Interactor

Users

Students

Teachers

Visitors

Admins

Domain

Grading
policies

Privacy
standards

SFU “style”

Donaldson/275

22

Interviewing


Interviewing stakeholders is a common way to get
requirements from them


Different types of interviews


Pre
-
set questions (e.g. questionnaire)


Free
-
form discussion


Individual


Group


Interviews are good for getting an overall view of
a system’s requirements


But …


Donaldson/275

23

Problems with Interviews


Users are typically specialists who have many
domain
-
specific assumptions and they tend to
use domain
-
specific jargon


Leads to many, sometimes subtle, misunderstandings


Specialists may find it


Difficult to explain important things they do


“I just do it”


May not bother mentioning things they think are
obvious


May assume developers are also experts in the domain

Donaldson/275

24

Problems with Interviews


Interviewer/interviewee power relationship
can causes problems


Interviewee may not offer ideas unless specifically
asked


Interviewer may have certain outcomes in mind
and try to steer the interviewee’s responses
towards what they want to hear

Donaldson/275

25

Effective Interviews


Interviewer is an open
-
minded listener


Truly listening is not always easy


Interviewer prompts interviewee with
suggestions


Doesn’t just ask “what do you want?”


But does listen carefully to try to figure out what
the interviewee is really saying


Concrete examples are usually better than
abstract notions

Donaldson/275

26

Scenarios


Concrete scenarios are usually easier for
people to relate to than abstract ones


Scenarios can be used to describe
requirements in context


Many different variations of this basic idea


One of the most common is “use cases”

Donaldson/275

27

Uses Cases


Use cases are usage scenarios


Descriptions of specific examples of how a user
might use a system


One use case describes one basic interaction
with a system in a semi
-
formal way


Use case forms typically have labeled sections


Descriptions are written in plain English


Diagrams can help


Must make an effort to be precise and complete



Donaldson/275

28

Sample GradeBook Use Case

Student views their grades

A CMPT 275 student has just received an email
from the TA saying their assignment 2 grade is
posted on the GradeBook. So they surf to the
GradeBook, login, choose 275 (they are taking
a few other courses that use the GradeBook),
and read their marks. They see what the
assignment was out of, what score they got,
and if the marker had any comments.

Donaldson/275

29

Sample GradeBook Use Case

Student views class statistics

After looking at their score for assignment 2 for
CMPT 275, a student wants to know where
they stand with respect to the rest of the
class. So the go to the 275 GradeBook stats
page where they see the class average, the
min/max marks, and a bar chart showing the
distribution of marks for this assignment.

Donaldson/275

30

Other Student Use Cases


Student reviews the marking scheme


Student checks all their marks at the end of
the semester


Student does “what
-
if” analysis to see what
scores they need to get a particular final
course %

Donaldson/275

31

Sample GradeBook Use Case

Teacher Enters Mark for a Single Student

The teacher wants to change a mark for one
assignment for one student in 275. So the go
to the GradeBook, select 275, go to the class
list, and choose the student by name. The
student record appears showing all the
students marks, and then they enter the new
mark.

Donaldson/275

32

Entering Marks


Entering marks is actually a big an important topic for a
GradeBook


Many use cases:


Single mark for a single student


Single mark for multiple students


Probably the most common use case


Multiple marks for a single student


Multiple marks for multiple students


Finding students is probably a separate case


Search by name (or part of name)


Search by student ID (rare, but useful)


Browsing an entire class list (useful if your browser has a
convenient page search function)


Donaldson/275

33

Entering Marks


Different teachers have different preferences


Depending on the situation


Interviews/observations may help determine
best methods


Or perhaps you need a highly
-
customizable
system that supports a variety of different
input methods


Donaldson/275

34

Ethnography


Observe day
-
to
-
day work done by users you’re
building the system for


You do not interact with the users


Sit back and take notes


In lab experiments, you might observe from
behind a two
-
way mirror


Often notice things that users would never
bring up in interviews

Donaldson/275

35

Ethnography


Useful for finding requirements based on how
people actually work


E.g. the GradeBook data entry use cases would
probably benefit from an ethnographic approach


Need to watch a variety of people entering data


See what teachers like and don’t like


See things like how they position multiple windows, or
how they place exams with marks, etc.

Donaldson/275

36

Ethnography


Also useful for eliciting requirements where
cooperation between people is involved


E.g. the GradeBook has problems if two or more
teachers try to edit the same student record at the
same time


An ethnographic study might watch people to see what
actually

they do when such conflicts arise

Donaldson/275

37

Ethnography Plus a Prototype


For a brand new kind of system, there’s may
not be anything to observe


So build a prototype and observe users using
it


Incremental software processes often
implicitly do things like this


First version given to users


Next version changed based on observation and
user feedback

Donaldson/275

38

Ethnography


Often extremely effective


But takes time and can be expensive


Need to watch people, take notes, and analyze notes


Not necessarily helpful for finding new features


Presence of an outside observer may cause
trouble


May interrupt normal workflow


May involve over
-
hearing private information

Donaldson/275

39

Requirements Validation


Requirements validation is about ensuring
your requirements will lead to building the
system the customer wants


Basically


Look for missing and inconsistent requirements


Find errors in requirements document to abvoid
costly changes later on


Donaldson/275

40

Requirements Checking


For each requirement, ask

1.
Is it necessary? Can it be replaced by a
combination of other features?

2.
Does it conflict with any other requirements?

3.
Is it realistic? Do we have the time, technology,
and know
-
how to implement it?

4.
How will we verify that we have correctly
implemented/achieved the requirement?


Donaldson/275

41

Requirements Checking


General techniques for checking requirements
include


System review by the development team in a
meeting


Creating a prototype


Generating test cases

Donaldson/275

42

Requirement Reviews


A formal for informal meeting to review the project’s
requirements


All stake
-
holders invited


For each requirement, ask:

1.
Is it testable/verifiable?

2.
Does everyone understand it? (For user requirements,
“everyone” includes end
-
users.)

3.
Is it clear why this requirement is here, and how it
relates to the system as a whole?

4.
Can the requirement be changed if necessary?


Also look for missing requirements, conflicts, and
other errors.

Donaldson/275

43

Planning Requirements
Management


Requirements are important


You plan many things including


How requirements will be elicited and analyzed


How the requirements document will be written and
formatted


Includes what (software) tools will be used


How they will be validated


How they will be changed?


Can anyone add new features? Can a programmer change their
feature if they know how to it better?


What is the cost of a change?


What impact will the change have on
other parts of the system?

Donaldson/275

44