01/25/2003

Requirements Engineering

 

Types of Requirements Engineering

CMM - Capability Maturity Model

- Established by SEI (Carnegie Mellon), defines levels (vaguely) and performs audits

- Level 1 - complete chaos

- Level 2 - repeatable, common sense methods

- Level 3 - more organizational basis, documented, standardized process

- Level 4 - quantitative control of the process; metrics taken and controlled

- Level 5 - continuous improvement of process

 

ISO 9000

- Target manufacturing, not just software processes

- More recognized

- Standard has been updated (9000, 9001, 9002)

 

Both CMM and ISO 9000:

Lack of advice about how to actually achieve steps, only descriptions of objectives;  does NOT tell you HOW to do requirements engineering

 

RUP - Rational Unified Process

- Jakobsen, Grady, Booch, Rumbaugh - modeling and notations for OO (after duking it out)

- Use case driven (scenarios)

- Iterative approach

- Who, how, what, when

- Artifacts:  stakeholder requests, vision, use case, other specs

- roles (system analyst)

* the Vision document is the MOST important one (10-page summary of objective/goal), covering high-level user/customer view, features w/assigned attributes

 

SEPA - Systems Engineering Process Activities

Emphasis on: requirements management prior to implementation/design

- support for all stakeholders (not just customers)

- extensive traceability

- separation of what versus how

- iterative

 

SEPA Activities and Artifacts -

 

Requirements Acquisition

- create natural language docs (plain English)

- try to capture RA session (videotape)

 

Stakeholder Requirements Model Creation

- transcribe natural language notes to graphical/textual models

- verify model and notes as often as possible, with stakeholders (often difficult)

- graphical representations that are sent back to stakeholders should be simple, easy to follow (workflow diagams, use cases) and presented appropriately to audience

- computational models (symbolic representations)- workflow, entity relationship, task decomposition

- while change can trigger constant iteration, the goal should be to improve the requirements acquisition to be fairly complete, by asking the right questions, choosing the right (knowledgeable expert) stakeholders

 

Requirements Modeling Synthesis

- merge models from different stakeholders into a single model

- this step should result in a Unified Requirements Model (URM)

- finding common tasks, common performers, mapping out relationships and interactions (entity relationship => semantic network)

* All Software Engineers should take an AI course - knowledge representation is key to developing real-world software

- scope should cover: what (scenarios), who (viewpoints), how

* Template covering:

Objectives:  Name, Goal, Frequency, Duration, Criticality, Completion Dependencies, Performers

What:  Task initialization/termination criteria, input data/event, output data/event, resources

How:  user interaction for start/finish, input/output

 

Separate Implementation-related requirements, Domain requirements, and Current Technology Solutions

- Non-functional & installation requirements model:  covers existing implementations (applications, systems, classes)

- Domain Requirements Model: entity relationships, tasks decomps, etc

- Technology Solutions:  available resources and descriptions, potential

 

*** Everything beyond this point is outside of the scope of this class ***

**************************************************************************

Domain Requirements Class Derivation

- implementation independent - domain reference architecture classes (DRAC)

- high-level behavior, dependencies

 

* OO heuristic tip:  assign methods, then data to objects - will lend itself to better encapsulation, decreased coupling

 

Non-Functional & Installation Requirements Class Derivation

Component Technology Registration

System Design & Evaluation

 

SEPA cannot be executed without Tool Support...

 

** RA Reports - header info (use for today's RA session)

Session #

Session TimeAndDate

Session Location

Stakeholder

Requirements Engineer

Session Purpose/Goal

Scenario Employed

Requirements Acquisition Techniques

Delivery of RA Report to Stakeholder

Receipt of Report Edits/Verification from Stakeholder