Geeks With Blogs
Mark Pearl

 

Aims of this chapter

  • Describe different kinds of requirements
  • Enable you to identify examples of different kinds of requirements from a simple description
  • Explain how different data gathering techniques may be used during the requirements activity
  • Enable you to develop a scenario, a use case, and an essential use case from a simple description
  • Enable you to perform hierarchical task analysis on a simple description

Summary

What, How and Why

The process works in a cycle..

Picture3

Why bother? The importance of getting it right…

  • A large number of IT projects fail due to bad implementations or incorrect specifications.
  • It is cheaper to analyse than to develop
  • If you identify the needs initially substantial savings in costs

What are requirements?

Two types of requirements typically identified

  • Functional Requirements – the core problem it aims to solve. What a product should do.
  • Non-functional requirements – size, speed…

Other types of requirements include…

  • Data requirements
  • Environmental requirements
  • User characteristics
  • Usability goals and user experience goals

Data gathering for requirements

The main purpose of data gathering for requirements is to collect sufficient relevant, and appropriate data so that a set of stable requirements can be produced./

3 common forms of data gathering include

  1. Interviews
  2. Questionnaires
  3. Observation

Interviews include…

  • Structured Interviews
  • Semi Structured Interviews
  • Unstructured Interviews
  • Focus Groups

Observation include…

  • Direct observation
  • Indirect Observation
  • Studying documentation
  • Researching similar products

Contextual Inquiry

Contextual inquiry is one of seven parts of contextual design, which is a structured approach to the collection and interpretation of data from fieldwork with the intention of building a software-based product.

Contextual inquiry rests on four main principles

  1. Context – go to the workplace and see what is happening
  2. Partnership – developer and user should collaborate in understanding the work
  3. Interpretation – observations must be interpreted in order to be used in design
  4. Focus – Keep the data gathering focussed on your goals

Data gathering guidelines for requirements

  • Focus on identifying stakeholders needs
  • Involve all the stakeholder groups
  • Support the data gathering sessions with suitable props

Data analysis, interpretation, and presentation

The aim here is to structure and record descriptions of requirements.

Various methods to diagram these at different levels including class diagrams, sequence diagrams, Entity Relationship Diagrams

Task Description

Descriptions of business tasks have been used within software development for many years. There are many different flavours of task descriptions including the following…

  • Scenarios – informal narrative description that allows exploration and discussion of contexts, needs, and requirements emphasizing the context
  • Use cases – focus on user goals, but emphasis is on a user-system interaction. A use case has one or more actors, goals and normal course (outcome desirable). Generally described graphically
  • Essential Use Cases – represent abstractions from scenarios and tries to avoid the assumptions of a traditional use case

An essential use case is a structured narrative consisting of three parts:

  1. Name that expresses the overall intention
  2. A stepped description of user actions
  3. A stepped description of system responsibility

Task Analysis

Main purpose is to investigate an existing situation, not to envision new products. Used to analyse the underlying rationale and purpose of what people are doing and what they are trying to achieve.

Hierarchical Task Analysis

Involves breaking a task down into subtasks and then into sub-subtasks. The starting point is the user goal, this is then examined and the main tasks associated with achieving that goal are identified. Where appropriate these tasks are subdivided into subtasks.

Posted on Friday, November 4, 2011 6:37 PM UNISA INF 3720 | Back to top


Comments on this post: INF3720 – Interaction Design Chapter 10 Summary

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © MarkPearl | Powered by: GeeksWithBlogs.net