Understanding Analysis: Personal Views, Components, and Importance of Requirements, Slides of Computers and Information technologies

This presentation by ian holyer explores the concept of analysis, emphasizing that it's a complex subject without a formulaic approach. The slides cover components of analysis, personal views, requirements, and their importance in individual projects and for project markers. The presentation also discusses the difference between requirements and specifications.

Typology: Slides

2010/2011

Uploaded on 09/06/2011

stifler_11
stifler_11 🇬🇧

4.6

(9)

272 documents

1 / 16

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Analysis, slide 1
Analysis
Ian Holyer
Ian Holyer
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff

Partial preview of the text

Download Understanding Analysis: Personal Views, Components, and Importance of Requirements and more Slides Computers and Information technologies in PDF only on Docsity!

Analysis

Ian Holyer

Ian Holyer

What is Analysis

Everyone agrees that analysis is very important, but

Everyone agrees that analysis is very important, but

nobody knows what it is

nobody knows what it is

One reasonably good book is

One reasonably good book is

  • An Intro to Requirements Engineering
  • by Ian K. Bray

It says analysis is "a hard subject to which there is no

It says analysis is "a hard subject to which there is no

formulaic approach"

formulaic approach"

Other Views

Beware that other people combine words in strange

Beware that other people combine words in strange

ways

ways

For example

For example requirements analysis

requirements analysis or

or requirements

requirements

specification

specification

I prefer

I prefer requirements capture

requirements capture

And other people differ about what includes what

And other people differ about what includes what

For example, the book I mentioned calls the whole

For example, the book I mentioned calls the whole

thing

thing

requirements engineering

requirements engineering

, with

, with

analysis

analysis

and

and

specification

specification

as components (along with

as components (along with

elicitation

elicitation

and

and

validation

validation )

Requirements

Requirements often end up as a bullet point "shopping

Requirements often end up as a bullet point "shopping

list" of things the project needs to achieve

list" of things the project needs to achieve

Do you really need it?

Do you really need it?

Thinking about a real shopping list, sometimes it is

Thinking about a real shopping list, sometimes it is

completely unnecessary, and sometimes it is vital

completely unnecessary, and sometimes it is vital

Requirements seem to fit the case where you have a

Requirements seem to fit the case where you have a

client, and the requirements summarise what you have

client, and the requirements summarise what you have

managed to extract from the client (by elicitation)

managed to extract from the client (by elicitation)

about what is required

about what is required

So, for a final year individual project, say, are

So, for a final year individual project, say, are

requirements needed?

requirements needed?

Project Markers

Look at it from the point of view of markers, e.g.

Look at it from the point of view of markers, e.g.

external examiners who only see the report

external examiners who only see the report

They want to see a conclusions section containing a

They want to see a conclusions section containing a

critical evaluation

critical evaluation

That means saying whether you achieved what you set

That means saying whether you achieved what you set

out to achieve, and to what extent

out to achieve, and to what extent

That is really difficult, if you didn't say

That is really difficult, if you didn't say at the start

at the start

what you were setting out to achieve

what you were setting out to achieve

You are all articulate, so you implicitly cover what you

You are all articulate, so you implicitly cover what you

are setting out to achieve in early chapters, but...

are setting out to achieve in early chapters, but...

...it would be better if you were more explicit about

...it would be better if you were more explicit about

your requirements (even if they are your own goals)

your requirements (even if they are your own goals)

What Are Requirements like?

If you have a client, textbooks will explain what the

If you have a client, textbooks will explain what the

requirements should be like and how to capture them

requirements should be like and how to capture them

They explain different kinds of requirements, e.g.

They explain different kinds of requirements, e.g.

  • Functional requirements: what the software will do
  • Efficiency requirements: how it will perform
  • Design constraints: e.g. what it must work with
  • Business constraints: e.g. when it must be done

But, with or without clients, I personally think the most

But, with or without clients, I personally think the most

important thing about requirements is...

important thing about requirements is...

Example: A Lift

Here are some poor requirements for a lift

Here are some poor requirements for a lift

  • when you press the call button, it comes
  • the doors open, and you get in
  • when you press the button for a floor, it goes there

the doors open, and you get out

Is there anything wrong with these?

Is there anything wrong with these?

(There is a lift on the commercial side of the MVB

(There is a lift on the commercial side of the MVB

building that satisfies these requirements, but it is

building that satisfies these requirements, but it is

terrible)

terrible)

Example: A Better Lift

Here are some less obvious requirements for a lift

Here are some less obvious requirements for a lift

  • when you press a call or floor button, no later press

prevents the lift going to your floor, except for a

stop on the way there

  • the lift always stops on the way up (down) if your

button press is not mechanically too late

  • if the lift announces it is going up (down) before it

arrives, it goes up (down) after it leaves

  • the lift hardly ever stops at a floor without anybody

getting in or out (why does our MVB lift do that?)

Google Surveys

Googling effectively is a difficult art, and needs

Googling effectively is a difficult art, and needs

practice, but Google is an extremely effective tool

practice, but Google is an extremely effective tool

There are some hints in the coursework descriptions, so

There are some hints in the coursework descriptions, so

make sure you read them and take them in

make sure you read them and take them in

A quick summary:

A quick summary:

  • look for list sites and review sites
  • look for new jargon to use in new searches
  • work fast and spread your net wide
  • refine queries that aren't working well

Specifications

A specification used to be a very tight, detailed,

A specification used to be a very tight, detailed,

complete technical description of what a program

complete technical description of what a program

should do, written in a contract style before starting

should do, written in a contract style before starting

It still is in critical systems, and may even need to be

It still is in critical systems, and may even need to be

written in a formal language and verified with software

written in a formal language and verified with software

tools (chip design is a very good example)

tools (chip design is a very good example)

With extreme programming, the emphasis is reduced,

With extreme programming, the emphasis is reduced,

because the first specification only needs to give an

because the first specification only needs to give an

initial direction for the project

initial direction for the project

After that, you can tighten it up and fill in details as

After that, you can tighten it up and fill in details as

you go along in the light of experience

you go along in the light of experience

Example: this unit

Some requirements/aims are:

Some requirements/aims are:

  • understand advanced software development
  • know about advanced techniques and tools
  • be well prepared for development in industry

Some specifications/objectives are:

Some specifications/objectives are:

  • be able to produce object oriented designs
  • gain experience in pair programming
  • be exposed to a variety of industrial areas