CSE403 Software Engineering, Autumn 1999

Gary Kimura

 

Lecture #3 Notes

Requirements

 

1)      Specifying requirements

a)      Today we’ll look at what makes up a requirement

b)      What is not in a requirement

c)      Ways of specifying requirements

d)      One person’s requirement is usually someone else’s design.

2)      Some angles on requirements

a)      What vs. How

b)      System requirements vs. Software requirements

c)      Functional vs. non-functional

d)      Requirements change

e)      Keep it realistic

f)        Expect unintended side affects (i.e., customers will use the system in ways you can never imagine)

3)      Examples of successful projects that met their requirements

a)      Caller ID, Call forwarding, etc.

b)      TCAS

4)      Examples of past failures or future failures (?)

a)      Therac-25

b)      Y2K

c)      Internet security

d)      Tower of Babel

5)      What should be in a requirement

a)      Desired effects of the system

b)      Know your intended customers and speak their language

c)      Likewise know the implementers and speak their language

d)      Justify your requirements so that the next person understands your reasoning

i)        Expect the requirements (goals) to change, due to customer changes, market place changes, technological changes

ii)       Expect the team to change during the product cycle.  One of the hardest tasks is to replace people in the middle of a project

6)      What should be left out

a)      Practically anything the customer doesn’t need to know to use the system

b)      Implementation details

c)      Over vs. under specified requirements

7)      How to specify requirements

a)      Natural Language to

b)      Structured Natural Language to

c)      Formal notation

d)      It is an iterative process, a good requirements writer bridges the gap between customer and implementer

8)      Any method for dictating requirements is only as good as the people are willing to use it

9)      Who writes the requirements and has major input

a)      Program Managers

b)      Customers

c)      Software Design Engineers

d)      Software Test Engineers

e)      Realistic

f)        KISS

10)  NT Lessons

a)      NT early days vs. later

b)      Natural Language

c)      Iterative with many redirections

d)      Various layers

i)        OS

ii)       UI

e)      Compatible and natural progression

i)        Current and proven technology, not bleeding edge technology

ii)       Cairo and OFS

f)        Sanity check

11)  Class Project TAG 2000

a)      Need a plan with milestones

b)      Model

i)        Don’t dwell on the exact model

ii)       Division of labor is important

iii)     Making sure you have a roadmap is important

c)      Requirements

i)        Important to get this written down

ii)       Keep this realistic

iii)     Expect them to change

d)      Design

i)        This is where parallel development really starts

ii)       Communication is still key

e)      Coding and component testing

f)        Integration and system testing

g)      Deployment and maintenance