Requirements Analysis Intro

From zedwiki

Jump to: navigation, search

Contents

Requirements Analysis Introduction

Benetech 20080415

Flashback: TechShare London

Intent: collect singular reqs and user stories /scenarios

The scenario based gathering was not done, because of the gathering mechanism used.

What is the nature of what we have gathered?

A collection of input from the real world

We have no measure of its completeness

It has no formal/legal status

Serves as raw material for the rest of the process

What do we want as the output of the Requirements Analysis process?

IEEE 830-1998 (doesnt really apply, but still:) 

 A Software Requirements Specification (SRS) is a complete description of the behavior 
 of the system to be developed. It includes a set of use cases that describe all of the 
 interactions that the users will have with the system. Use cases are also known as 
 functional requirements. In addition to use cases, the SRS also contains nonfunctional (
 or supplementary) requirements. Non-functional requirements are requirements which impose 
 constraints on the design or implementation (such as performance engineering requirements, 
 quality standards, or design constraints).

RA results in an SRS equivalent.

Needs not be a complete SRS: already established patterns (DAISY-today) can be implicit. Minimally a manifest that defines all changes in the ways that stakeholders can interact with the system

This would be a living document for a certain period of time (spiral development, prototypes).

It (and not the requirements themselves) would form the document that formally defines what we agree to achieve.

Core problem: we may have to stipulate that a revision would provide enough effect to be worthwhile.


Who is the consumer of the SRS?

  • The DAISY Community
  • NISO
  • The Z3986 Committee (A "contract" which we can refer to during the following process)

Notes on user stories

Benefits of scenarios / user stories:

  • puts requirements into a communicable and weightable (in terms of importance) context
  • provides for a natural grouping mechanism (can help scoping profiles)
  • can form the main body of declarative part of the SRS

1. A user story has a stakeholder as 1st person (remember: stakeholder examples: end users (current and future), producers, publishers, distributors, tool providers, distributors) 2. What is described is an interaction enabled by the deployment of the system that is being modelled 3. Describes a complete interaction sequence.

Approaches for requirements analysis

How do we get from here to an SRS equivalent?

Reqs Grouping/taxonomy alternatives

  • Ad Hoc (identifying a set of high-level themes, gradually more finely grained)
  • Through building a scenario super structure and relinking
  • Both of the above
  • Something else...

Typically a multidimensional categorization

  • "Themes"
  • Functional, non-functional
  • Identify user class (stakeholder) that will benefit from the implementation
  • Identify priority/importance (how intense is the effect on the user)
  • Measure viability, cost
Retrieved from "http://www.daisy.org/zw/Requirements_Analysis_Intro"
Personal tools