Analysis Stage Customer Requirements

1
Analysis Stage Customer Requirements

• The goal understanding the customer's
  requirements for a software system.
• involves technical staff working with customers
• involves all the stakeholders in the system

2
Problems when gathering Customer Requirements?

• Who ARE the stakeholders?
• Stakeholders don't really know what they want.
• Stakeholders express their requirements in their
  own terms, in the language of their organization
• Different stakeholders may have conflicting
  requirements
• The requirements evolve
• New stakeholders may emerge on the scene

3

• In the Customer Requirements Phase only the
  user's environment was described.

4
Customer Requirements Viewpoints

• Partitioning Identifies the structural
  relationships between system components
• Top-down design
• Bottom-up design
• Projection Identifies different ways of looking
  at a problem
• What is the best solution?
• How is the problem currently solved if it is?
• Are there alternative solutions that will work?

5
Customer Requirements Viewpoints

• Good analysts must be very sensitive to different
  views.
• There is no systematic way to factor them into
  the analysis process.

6
Remember

• In the Customer Requirements Phase only the
  user's environment was described.

7
How is the Design Phase Different?

• In the Design Stage the System ("product") is
  described in terms of the software environment as
  well as the user's environment.

8
A careful, thorough design, increases a product's

• dependability
• maintainability
• (higher) quality

9
The Better the Design --

• The more Effective and Efficient the
  implementation.

10
In some organizations the Design phase is rather
formal!

• Use formal specification notations and languages
• Conform to set standards of quality and content
  for the product (local standards)
• Verify and Validate the specification

11

• Verification and Validation?
• Are they different?

12

• Validation Are we building the right product?
• Verification Are we building the product right?

13

• The Design phase should clearly and precisely
  describe the essential functions, performances,
  design constraints, attributes and external
  interfaces required to solve the problem.
• Each requirement is defined so that its
  achievement is capable of being objectively
  confirmed.
• Adapted from IEEE Standard for Quality Assurance
  Plans

14
Purpose of the Design Phase

• 1) to translate the user-oriented requirements
  into a form that is meaningful in terms of
  software development
• 2) Ideally to create a design so that an
  automated (tool intensive) development of the
  software product is possible
• 3) to commit our organization, and that of the
  customer, to a set definition of the product
• Adapted from IEEE Standard for Quality Assurance
  Plans

15
The Design Stage is for the software team.

• Why do the specifications twice?
• Why not do the design directly and skip the
  Customer Requirements docs?
• Why can't we code directly from the Customer
  Requirements Document?

16
Why a Design Phase?

• The Customer requirements phase is
• By definition imprecise! --- Why?
• A general outline, it is an initial planning
  document.
• The Design stage is a much more formal
  specification of how the problem will be solved!

17
In the Design Phase

• We are looking toward the eventual automation of
  the development process.
• The Design is another opportunity to make sure
  the "plan" meets the users needs.
• The Design finalizes the definition of the
  product. (??!!)

18

• Moving from
• Customer Requirements to Design

19
What is a good design?

• A good design is one that creates a solution
  which satisfies the software requirements.

20
Designing solutions have three stages
1) Study and Understand the Problem
21
Design problem have three stages

• 2) Identify more than one possible solution.

IDEAS?
22
Design problem have three stages

• 3) Use some form of abstraction to describe the
  solution

23
Design

• 1) Study and Understand the Problem
• Examine the problem from all possible viewpoints
  to discover the design requirements. Note Design
  requirements are not the same as the
  customers/users requirements!
• Identify and talk to stakeholders.

24
Design

• 2) Identify one of more possible solutions
• There is rarely only one possible solution.
• Evaluate alternative solutions. Select the most
  appropriate depending on the designer's
  experience and available resources
• 3) Use some form of abstraction to describe the
  solution
• Use graphical, formal or other descriptive
  notations to describe the components of the
  design!

25
The design process involves "decomposing" the
system.

• Develop system models at different levels of
  abstraction.
• The more design alternatives provided, the more
  likely the solution will accurately reflect the
  design.

26

• Design takes place in overlapping stages.

27
Design for large scale software includes

• Architectural design
• Identify sub-systems
• Abstract specification
• Specify sub-systems
• Interface design
• Describe sub-system interfaces

28
Design for large scale software includes

• Component design
• Decompose sub-systems into components
• Data Structure design
• Design data structures to hold the problem's data
• Algorithm design
• Design algorithms for problem functions

29
In principle ...

• Top-down design involves starting at the
  uppermost components in the system and working
  down
• level by level.

30
In practice ...

• Large systems design is never really top-down!
• Some branches are designed before others. Why??
• Designers reuse experience (and sometimes
  components) during the design process.
• Some components lend themselves to quick and easy
  solutions.
• Manager/Customer wants to see something early in
  the process.

31
The Design has different purposes

• Basis for detailed implementation
• Serves as a communication medium between the
  designers of sub-systems
• Provides information to system maintainers about
  the original intention of the system designers

32
The Design Document that describes the
problems solution

• The Design document is for programmers and other
  developers. It includes
• (1) Graphical notations
• (2) Program Design Languages (PDL)
• (3) Informal text

33

• What are the qualities of a GOOD Design?

34
Design Quality

• Design quality is an elusive concept.
• Quality depends on specific organizational
  priorities
• A "good" design may be the most efficient, the
  cheapest, the most maintainable, the most
  reliable... or not!
• A "good" design may be the easiest and quickest
  to create or not!

35
Design Quality

• The understandability of a design is critical!
• Because anyone changing the design must first
  understand it.
• Change is inevitable!