1. Chapter 11 Analysis Concepts and Principles

2. Introduction: What Are the Real Problems?
the customer has only a vague idea of what is
required
the developer is willing to proceed with the
"vague idea" on the assumption that "we'll fill in
the details as we go"
the customer keeps changing requirements
the developer is "ratcheted" by these changes,
making errors in specifications and development
and so it goes ...

3. Requirements Analysis
Requirements Analysis - is a software engineering task that bridges the gap between system level requirements engineering and software design

4. Analysis a bridge between system engineering and software design

5. Requirements Analysis
Five areas of efforts
Problem recognition
Evaluation and synthesis
Modeling
Specification
Review

6. Techniques for Requirements Elicitation
1. Initiating the process – conduct a meeting or interview.
Some questions to ask by the analyst:
who is behind the request for this work
Who will use the solution
What will be the economic benefit of a successful solution?
Is there another source for the solution that you need?

7. …Techniques for Requirements Elicitation
2. Facilitated Application Specification Techniques (FAST)
Meeting (often at neutral site)
Establish meeting rules
Agenda to cover important points
A facilitator -- best if not customer or supplier
Definition mechanism
Understand goal -- to identify problem, specify a preliminary set of requirements
To set some ground rules for out customer-developer meeting.
Develop the best estimate of process flow diagrams to help them understand and help generate questions.
Develop ACDs where feasible.
Prepare some architecture flow diagrams, if possible.
Be prepared to show some of these to create a framework for asking questions.
Construct a few scenarios of what you think is happening.
You can almost think of process flow diagrams as an organized way to describe scenarios of what is going on.
Luz to take notes -- to be distributed.
Agenda
RAV - read problem statement again.
Open floor to questions
RAV moderate
Ask for volunteer groups to show process flow diagrams.

8. …Techniques for Requirements Elicitation
Facilitated Application Specification Techniques (FAST)

9. …Techniques for Requirements Elicitation
3. Quality Function Deployment
Normal Requirements
What will make customer happy
Expected Requirements
Unstated requirements that are so “obvious” that they need not be stated
Unexpected Requirements
Enhancements beyond customer requirements
Concept developed by the Japanese

10. Use-Cases
A collection of scenarios that describe the thread of usage of a system. Each scenario is described from the point-of-view of an “actor”—a person or device that interacts with the software in some way
Each scenario answers the following questions:
What are the main tasks of functions performed by the actor?
What system information will the actor acquire, produce or change?
Will the actor inform the system about environmental changes?
What information does the actor require of the system?
Does the actor wish to be informed about unexpected changes?

11. Analysis Principles Operational principles
Represent and understand information domain
Define functions that must be performed
Represent behavior of software (to external events)
Partition information, function and behavior models hierarchically
Move from essential information to implementation detail

12. Guiding Principles Understand problem before analysis
Develop prototypes for HCI
Record the origin of and the reason for every requirement
Use multiple views of requirement
Rank requirements
Eliminate ambiguity
Note KSC CLCS problem of lack of rationale documentation on earlier system.

13. Analysis Principle I: Information Domain
Software processes data
Payroll processing
Computing control signals for radar system
Software also processes events
Timer went off -- time to calculate a control
Sensor turned on -- indicates intruder
Heart rate monitor exceeded threshold -- indicates fibrillation.

14. …Information Domain Modeling Three views of information
Information content
Information flow
Information structure
Modeling
Functional Models
Behavioral Models

15. Analysis Principle II: Modeling
Functional Models
Behavioral Models

16. Analysis Principle III: Partitioning
Note distinction between essential and implementation views.
Essential view captures the conceptual ideas, but omits the details.

17. Analysis Principle IV: Essential and implementation view
The essential view of a software requirements presents the function to be accomplished and information to be processed without regard to the implementation details.
Note distinction between essential and implementation views.
Essential view captures the conceptual ideas, but omits the details.

18. Prototyping
Prototyping helps Clarify requirements, Identify missing requirements and Help define user interfaces.
1. Selecting the prototyping approach
Throwaway
Evolutionary -- a potential problem is that intended throwaways become evolutionary

19. Prototyping Important questions underlying prototyping
Customer commitment -- must be involved
Must commit resources for evaluation
Must be capable of making requirements decisions in timely manner

20. …Prototyping 2. Methods and tools
Fourth Generation Techniques -- program application generators
Reusable Software Components -- build from existing components
Formal Specification and Prototyping Environments
Translate specifications into code

21. Specifications Specification principles
Separate function from implementation
Develop a model
Establish the environment
Define how software interacts with environ.
Create Cognitive model -- how world sees it
Recognize specs as imperfect
Flexibility -- be amenable to change

22. 2. Representation Format and content relevant to problem
Information should be nested
Multiple layers or levels
Diagrams should be consistent in use
Representations should be revisable

23. 3. Software Requirements Specifications

24. Specification Review
Software requirements specification is conducted by both the software developer and the customer
Macroscopic Level
View from the top
Goals met ?
Alternatives explored ?
Customer satisfied ?
The specification becomes a “contract” for software development.

25. End