1. requirements analysis

   1. determine the client's problem

      1. the domain in which the problem occurs

      2. the problem

      3. the criteria that solve the problem (not the problem's solution)

   2. information passes between client and developer

      1. the client describes the domain and problem

      2. the developer characterizes the solution but doesn't solve the problem

2. issues

   1. defining and extracting the necessary information from the client

   2. organizing extracted information

      1. organization imposes patterns, emphasizing irregularities

   3. fixing problems like inconsistencies, ambiguity, unresolved trade-offs

   4. avoiding design

3. general analysis techniques

   1. use divide and conquer to partition the problem

   2. partitions can emphasize various problem characteristics

      1. functional partitions emphasize behavior

      2. object-oriented partitions emphasize entities

      3. state partitions emphasize characteristics

      4. projections emphasize points of view

   3. several partitions may be used in one analysis

4. specific analysis techniques

   1. informal analysis, formal analysis, or protyping

   2. informal analysis

      1. almost pure information gathering

      2. meetings, meetings, meetings

      3. flexible, exploratory

   3. formal analysis

      1. many techniques, all leading to processed information

      2. structured analysis technique (sat)

         1. functional partitioning based on data transformations

         2. data flow diagrams (dfd) or bubble diagrams

         3. each process (bubble) is a data transformation

         4. low-level mechanism and minor details are hidden or ignored

         5. no processing details (how), just data transformations (what)

         6. dfd hierarchies (bubbles inside of bubbles)

         7. dfd data flows are unstructured

         8. data dictionaries define the structure of data flows

         9. weak dfd semantics means limited validity checks

         10. the structured analysis technique

             1. start with a one-process context diagram

             2. subdivide the context bubble to identify major data transforms

             3. repeatedly subdivide processes until all important data and transforms are modeled.

             4. partition the system to identify user-system, new-old interfaces

      3. object-oriented analysis (ooa)

         1. entity-based analysis

         2. objects have state, provide services, and are related to other objects

         3. current hot-topic due to realism, stability, ability to change

         4. there are many, many ooa techniques

         5. an object is a thing (not necessarily tangible) in the problem domain

         6. objects have attributes (state) that characterize an object and distinguish it from other objects

         7. similar objects are grouped into a class

         8. objects offer services, usually accessed via messages

         9. relations among classes are is-a (generalization-specialization) and part-of (aggregation, assembly, containment)

            1. multiplicity

         10. doing ooa

             1. identify objects, attributes, relations, and services

             2. use grammatical analysis to get objects (nouns), attributes (adjectives) and services (verbs)

             3. further analysis determines inter-object relations (is a, part of) and multiplicities

             4. this process iterates, under design rules and customer guidance

      4. entity-relation (er)

         1. like ooa, but no services or functions

         2. most frequently used for database applications

         3. entity (data), attribute, and relation

      5. other formal analysis techniques

         1. structured analysis and design technique - more boxes and arrows

         2. problem statement language (psl) and problem statement analyzer - a formal language with processor

         3. requirements statement language (rsl) and the requirements engineering validation system (revs) - another formal language with processors, oriented toward real-time systems

   4. prototyping

      1. early experience with actual systems sharpens the requirements

      2. quickly and cheaply create versions of the system to solve the problem

      3. throw-away and evolutionary approaches

         1. throw-away

            1. inexpensive (to do) and fast development

            2. explore poorly understood problem parts

            3. cycles between requirements and prototyping

            4. throw away the finished prototype

         2. evolutionary

            1. formal, but early, development

            2. demonstrate well understood problem parts

            3. keep the finished prototype for further development

      4. when to prototype, and what kind

         1. experience and ability

         2. ground rules - problem maturity, change expectations

This page last modified on 31 January 2000.