Understanding Problems & Defining Scope: Effective Software Design, Lecture notes of Computers and Information technologies

Download Understanding Problems & Defining Scope: Effective Software Design and more Lecture notes Computers and Information technologies in PDF only on Docsity!

System Building 2

Lecture 18

Requirements Capture

You should arrange a time for

your coursework demonstration

with your tutor today

Requirements Capture

The ‘Requirements’ are a prerequisite for good

systems design

They are captured during Analysis

The process is broadly (not rigidly)

Understand the problem

Define/clarify the scope, context and objectives

 Broadly model possible solutions

Build specifications of most promising solutions

Select preferred solution & ensuring client agreement

Understand the problem

 To do this you need access to resources

 It is common to first have an interview at a ‘high’ level to:

 Break the ice

 Get an overview of:

 Problem

 Domain

 Bounds (physical, fiscal, political, performance)

 Line management structure / Key personnel

 Who knows what?

 Who has authority?

 Is there any ‘history’?

 Obtain permissions to:

 Set up meetings

 Inspect elements (documents, files, systems, areas…)

 Issue questionnaires…

Define/clarify scope/context/objectives  (^) The tools used here include  (^) Questionnaires  (^) Structured development meetings (eg. See FAST in Pressman)  (^) Definition  (^) Discussion  (^) Proposals  (^) Agreements  (^) Inspections/Interviews  (^) Cost benefit analysis/ Risk analysis  (^) Models (both abstract and concrete)  (^) Tables of standard metrics  (^) Data Dictionary

Define/clarify scope/context/objectives  The information gathered here includes

Functional requirements

Performance requirements

Reliability requirements  (^) Maintenance requirements

Training requirements

Costs/benefits

Surrounding system models & functionality

Data structures (existing and required)

Data dictionary entries

Broadly model possible solutions  The documentation produced includes

For each solution the outlines of:  (^) Software  (^) Hardware  (^) Liveware (wetware, personnel)  (^) Dictionaries  (^) Accommodation  (^) Controls  (^) Costings  (^) Data (organisation of)  (^) Prerequisites (training, file preparation etc)

Broadly model possible solutions  Models  Schedules  Dictionaries  Prototypes  Simulations  (^) Architecture  (^) Software  (^) Hardware  Deployment

Select preferred solution ensuring client agreement  (^) The report is presented to the client  (^) Discussions ensue  (^) Points are clarified  (^) A solution is chosen  (^) By the client  (^) We may be asked to extend or reduce the brief and re-present  (^) We are now in a position to  (^) Start the analysis proper on

 A large system

 A complex system

 (^) Start the design on

 A small system

 A simple system

The order may vary

While modelling possible solutions

We may decide that the scope was too narrow

The problem was misunderstood

Etc. Requiring iteration of the first elements

Or it may be decided that a prototype is required

 Which may then reduce the need for some aspects of

the specification (which may be defined by the

prototype)

Etc

 (^) Today most of our work is on existing systems  (^) New paradigms are developing  (^) Extreme programming  (^) Development of ideas from  (^) ‘Best Practice’  (^) Maintenance and hot fixing of code  (^) And a need to reduce time between inception and delivery  (^) Look at my small code examples  (^) They are a bit simplistic and not written for this purpose but…  (^) I determine requirements and rough out a design  (^) I write a simple test harness and stubs  (^) then repeatedly

 Code a unit

 Run the tester

 (my testers merely check it runs. Students find the bugs, it’s good for them :-)

 Debug if needed

 (^) Review and plan progression  (^) Turn the stubs into test harnesses and create more stubs…