February 22 - Requirements Engineering – Lecture Notes

 

From previous lecture, RA Plan Construction

 

Requirements Representations and Tools

 

* Mental Models ó Scenarios :  there should be ONE that describes the whole system, an abstract model with a single path

 

·         Artifacts of Requirements Phases (slide 9 – Representing Traceability)

o        Acquisition

§         Plan

§         Session Report

§         Use Cases/Scenarios

§         Mental Models

§         Viewpoint Hierarchy

o        Modeling

§         Text documents

§         Graphical Models

§         Computational Models

o        Analysis

 

Question:  why is traceability not documented in today’s software development environment?  It’s too expensive, and there’s no tool support.  Objective is to teach the ideal, and give guidelines for reality. 

 

GNAT – bug tracking tool

 

UML – graphical representation of models (most commonly used in object-oriented programming)

 

Text-based Requirements Representation

 

IEEE Recommended Practice for SRS (Software Requirements Spec)

IEEE Guide for Development System Requirements Specs

·         Well formed Requirements (page 11)

o        Blah blah blah.  a statement of system functionality (a capability) that can be validated, that must be met or possessed by a system to solve…”

 

** Assignment 2 – find a requirements document and evaluate it, in terms of its intended audience, content, etc… more details to come

 

·         This lecture is straight out of the book, btw

 

4:  Granularity – One of the most difficult things in creating this document is determining how you organize the requirements to match the different product’s attributes?  Behaviors versus constraints, etc.

 

5:  Spec docs (SRSs)

Needs -> Features = Problem -> Solution … this is not necessarily what’s “good”, but it’s what the industry currently practices. (slide 7)

Spec docs is somewhere between requirements and features

 

 

The Vision Document

·         If you are going to a document, this is the ONE document you should do.  Everyone can read it, it’s high-level.  Minimal, no excuse

·         It is easy to create v1.0, difficult to maintain 2.0, etc

·         For a legacy system, good to capture high-level information, and then take a Delta approach (document new and different features)

·         A true requirements document should take feedback, and be involved in the development process, to act as a directive, not as an after-the-fact document.

 

Modern Software Requirements Specification (SRS)

·         SRS – complete conceptual model

·         Who should write it?  All of them – developers, testers, requirements engineers

·         SEI-CMM and ISO care mostly about having a standard way for deriving this document

·         Contains the beginnings of design of the system

·         Use-case :  what is the external view of functionality in the system

Question: how long does the SRS take, when does it start?

Answer:  decisions for the system should be documented, so this document becomes a means for tracking the decisions that are made.

 

Demo of Text-based Requirements Representation Tool

(Tom – Rational Requisite Pro)

 

Rational Requisite Pro:

 

Text fragments

·         informal text can be very expressive

·         by separating into fragments, able to group into categories

·         still need to transition to more formal

·         no automated checking

 

Acquiring – easy, directly from meetings and correspondence

Representing – easy: text is flexible, use common phrasing indicating strength of requirement/constraint

Analyzing – hard:  text structure and semantics aren’t amenable to automated reasoning

Refining – hard:  merging and versioning is manual

 

Use cases, requirements/features linked and hierarchical

 

ASSIGNMENT 2:

Instructions:

Find a requirements document

Evalute the document in terms of:

·         structure (the outline of the document)

o        compliance to req doc standards

o        usability

o        contains the “right and necessary” info

·         content

o        quality of info

o        level of detail

o        type of requirements included

·         understandability (by developer, tester, marketing, project manager)

 

Deliverable:  hardcopy of evaluation document, original requirement document (or reference)  approximately 5 pages

 

Evaluation Criteria:  document presentation, requirements document, coverage of evaluation, quality of evaluation