Introductory Software Engineering CSE100 Lecture 2: Requirements

1
Introductory Software EngineeringCSE100Lecture
2 Requirements

• Dr Siobhan Devlin

2
We have already learned that

• Software Engineering is
• Systematic, controlled, scientific approach to
  the
• development,
• operation, and
• maintenance of Software
• Using appropriate tools and techniques
• According to the constraints you are working
  within

3
Also, that SE is

• Not only the technical side of the problem
  solving, but also the project management side
• people,
• products, processes, quality,
• budgets,
• Resources/constraints
• schedules, etc

4
And that

• There are systematic ways of working through any
  job/project/set of tasks to maximise chances of
  success
• Agree spec.
• Plan project.
• Communicate plan to team.
• Agree and delegate actions.
• Manage, inform, enable the team.
• Check progress, adjust plans.
• Complete, review and report.

5

• You have done some of this in CIF101
  (Professionalism and Personal Skills)
• It is not our intention to repeat this in this
  module but it is useful to put your emerging
  skills into practice in the right context
• This is partially why weve done the group
  activity of last week and the bridge build

6
Last week we started to learn that

• There is a continuous lifecycle or set of
  processes to the way in which software should be
  systematically developed

7
Software Development Processes
Changing the software in response to changing
demands
Checking that the software is what the
customer wants
tion
Evolu
Validation
Specification
What the System should do and its
development constraints
Development
Production of the software system
The 4 generic activities in all software
processes, (Sommerville, 2004)
8
Software Development Lifecycle
Requirements
Evaluation
tion
Evolu
Validation
Specification
Analysis
Development
Testing
Design
Development
May be different professionals doing each stage!
9
Question

• Is this lifecycle to be followed for all types of
  software development?
• What do you think?
• Yes or no?
• Why?
• Before you decide, think about this

10
There are many different types of Software System

• Systems Software
• Applications Software e.g.
• Information Systems
• Business Systems
• Educational Systems
• Entertainment Systems
• Decision Support Systems
• Multimedia Systems
• Network Systems
• etc

11
Within these Types, SW can be

• Either Stateful
• System remembers what you were doing last time
  you were on it
• retains configuration settings
• Or Stateless
• WWW is basically stateless but cookies, Server
  APIs add state to it
• Either Generic (e.g. MS apps)
• Or Bespoke (e.g. NHS, e.g. student final year
  projects)
• Configurable
• Reusable or
• Reverse Engineered do this to existing SW to
  produce new/bespoke SW (its controversial)

12
The Question, again

• Is this lifecycle to be followed for all types of
  software development?
• What do you think? Discuss in small groups
• Yes or no?
• Why?

13
Software Development Lifecycle
Requirements
Evaluation
tion
Evolu
Validation
Specification
Analysis
Development
Testing
Design
Development
14
No matter what SW type

• The development of any system requires the same
  attention to detail
• Bear in mind though, that depending on
• the type of system
• the development methodology chosen
• There may be more emphasis on some tasks and less
  on others - but they are all still very important!

15
Specification

• Today we begin looking at Specification the 1st
  stage of which is requirements

16
Software Specification

• To define precisely the
• Functional Requirements - what the software must
  do e.g. load graphics, update stock level, print
  report etc
• Non-functional Requirements - how the software
  must work in context/in practice, what are the
  constraints on the operation e.g. timing,
  accessibility, user interface, etc

17
User Specification of Requirements

• Developer needs to establish clear usability and
  other design goals at the start of the project
• Start by considering
• Users what are their characteristics?
• Goals what does the user want to achieve?
• Context in what kind of environment, with what
  sort of constraints? (e.g. is it online? is the
  data sensitive?)

18
Guidelines for Gathering Requirements

• Identify
• Stakeholders, and stakeholders needs
• Involve
• all stakeholder groups
• more than one person from each group
• Use
• a variety of data-gathering methods
• Support
• data-gathering sessions with props e.g. paper
  prototypes, storyboards, company documentation
• Be realistic about you can achieve at this stage

19
Questions when gathering/ interpreting
Requirements

• Who decides what the requirements are, the
  developer or the user?
• Does the user understand the system well enough
  to specify requirements?
• Does the developer understand the users needs?
• Can the developer and the user communicate?

20
Why is the Requirements stage so important?

• Making a crucial misstep at this phase can
  easily lead to large amounts of rework when the
  customer simply cant accept a system the way it
  was developed (Dieste, Juristo Shull, 2008)
• Its more costly to correct mistakes later in the
  lifecyle

21
Dont clever process models mean that getting
requirements exactly right, from the start, isnt
such a big deal?
22
Noand yes!

• Incremental development, prototyping or agile
  methods (which well learn more about later) can
  help
• because they mean small chunks of development are
  shown to the client frequently/regularly.
• A working prototype allows stakeholders to
  examine not only how the prototype looks but what
  it does how it functions.
• But, the easiest/best way to develop a high
  quality system, that meets user requirements, is
  to get the requirements right in the 1st place!

23
How to get requirements from a client

• Requirements Elicitation
• In a 2008 study by Dieste, Juristo Shull, 43
  different Requirements Elicitation techniques
  were uncovered
• They examined literature in SW Engineering and
  other fields of study such as Marketing

24
4 General Requirements Elicitation Approaches

• Interview based methods
• Questionnaires
• Introspection Observation
• Contrived techniques
• Each is effective in context,
• Some more suitable than others for different
  problems and domains
• Some are quicker, need less preparation, elicit
  more requirements or different types of
  knowledge, concentrate more on different parts of
  the task....etc

25
1. Interview Based Requirements Elicitation

• Many types, focusing on different things e.g.
• Unstructured Interviews
• General questions to help user talk about the
  problem domain
• Why or when might structured interviews not be
  useful?
• The SW developers arent experts in the problem
  domain
• May be useful to do unstructured followed by
  structured, or to do semi-structured

26
Further interview e.g.

• Interviews to determine critical success factors
• Interviews to construct Data Flow Diagrams

27
2. Questionnaire based Requirements Elicitation

• Self explanatory BUT
• Questionnaire design is very important, very well
  researched
• You should read up on it before you write your
  own questionnaire
• What data are you looking for? Quantitative/Qualit
  ative? How to analyse the results? How to word
  the questions? How many questions is appropriate?
  Who to give it to? The need to pilot...etc
• Same issue as with Structured Interview

28
3. Introspective Observational methods for
Requirements Elicitation

• Here you get info about the users tasks and
  their values e.g.
• Protocol Analysis
• User thinks aloud while solving a problem
• Documentation Analysis
• Observe the user at work

29
4. Contrived techniques for Requirements
Elicitation

• Ask users to do an artificial task to see what
  are priorities, goals, sub-goals etc. e.g.
• Card Sorting
• User arranges cards showing similar concepts from
  the problem domain into groups
• Textual Laddering
• Short questions help determine important concepts
  which are then arranged into a hierarchy
• Mock Ups
• Scenarios
• Storyboarding

30
Results of the 2008 study

• Across 30 comparative studies
• Interviews are best, but should have some
  structure prepare a few questions beforehand
• It results in more user needs being identified,
  lends focus and speed
• Introspective techniques (protocol analysis) are
  least effective
• Interviewing, card sorting, laddering quicker,
  easier simpler

31
Results of the 2008 study

• Contrived techniques are not best used alone but
  good when used along with interviews to gain
  specialist knowledge
• Especially true for laddering, but may be as time
  consuming as interviews
• Sorting less effective than interviews (but
  quicker!) but useful in conjunction

32
Activity Scenario 1

• Lovely Smellies is a business that sells
  animal-cruelty-free toiletries. They would like a
  website to market their products.
• Your boss is a friend of the business and has
  already told them that youll undertake the work
  for them.
• This is all the information you have so far.

33
Activity Scenario 2

• The Head of the Department of Computing,
  Engineering Technology, Uni of Sunderland,
  would like a SW system that is a Help Point for
  students
• It should show each member of staffs
  responsibilities, so that students know who to
  contact for whatever question/problem relating to
  student life
• It could be internet based or kiosk based

34
Activity

• In groups of 5-8, decide on the requirements
  elicitation technique or techniques youll use
• Why have you chosen these?
• What further information to you need from the
  client before you can start designing your SW
  solution?

35
References

• Dieste, O., Juristo, N. Shull, F.(2008)
  Understanding the customer what do we know about
  requirements elicitation? IEE Software
  March/April 2008.