Docstoc

REQUIREMENT ENGINEERING C

Document Sample
REQUIREMENT ENGINEERING C Powered By Docstoc
					                                           Software Engineering




                           Ch9
                  Requirements Engineering

                              N.L. Hsueh




  本投影片僅供教學用
                                                           1
N.L. Hsueh, SE-Lab IECS FCU
                                           Software Engineering




        We spend a lot of time – the majority of total
        project time – not implementing or testing, but
        trying to decide ―what to build‖

        Brian Lawrence




                                                           2
N.L. Hsueh, SE-Lab IECS FCU
                                                Software Engineering

                          Topics covered

       Requirements engineering process
       Requirements elicitation techniques
       Requirements specification techniques
       Requirements document
       Requirements validation
       Requirements evolution




                                                                3
N.L. Hsueh, SE-Lab IECS FCU
                                                   Software Engineering

                 Requirements engineering

       The process of establishing the services that the customer
        requires from a system and the constraints under which it
        operates and is developed
       Requirements may be functional or non-functional
           Functional requirements describe system services or
            functions
           Non-functional requirements is a constraint on the system
            or on the development process

       What is a requirement?
          It may range from a high-level abstract statement of a
           service or of a system constraint to a detailed
           mathematical functional specification


                                                                        4
N.L. Hsueh, SE-Lab IECS FCU
                                                   Software Engineering


         Requirements definition/specification
       Requirements definition
          A statement in natural language plus diagrams of the
           services the system provides and its operational
           constraints. Written for customers
       Requirements specification
          A structured document setting out detailed descriptions of
           the system services. Written as a contract between client
           and contractor
       Software specification
          A detailed software description which can serve as a basis
           for a design or implementation. Written for developers



Requirements specification

                                                                        5
N.L. Hsueh, SE-Lab IECS FCU
                                                                       Software Engineering
                                Definitions and
                                specifications
     Requirements definition

       1. The software must provide a means of repr esenting and
       1. accessing external files created by other tools.


     Requirements specification

    1.1 The user should be provided with facilities to define the type of
    1.2 external files.
    1.2 Each external file type may have an associated tool which may be
    1.2 applied to the file.
    1.3 Each external file type may be represented as a specific icon on
    1.2 the user’s display.
    1.4 Facilities should be provided for the icon repr esenting an
    1.2 external file type to be defined by the user.
    1.5 When a user selects an icon repr esenting an external file, the
    1.2 effect of that selection is to apply the tool associated with the type of
    1.2 the external file to the file represented by the selected icon.

                                                                                       6
N.L. Hsueh, SE-Lab IECS FCU
                                                 Software Engineering

                        Wicked problems

       Most large software systems address wicked problems
       Problems which are so complex that they can never be fully
        understood and where understanding develops during the
        system development
       Therefore, requirements are normally both incomplete and
        inconsistent




                                                                     7
N.L. Hsueh, SE-Lab IECS FCU
                                                     Software Engineering

                 Reasons for inconsistency

       Large software systems must improve the current situation. It
        is hard to anticipate the effects that the new system will have
        on the organization
       Different users have different requirements and priorities.
        There is a constantly shifting compromise in the requirements
       System end-users and organizations who pay for the system
        have different requirements
       Prototyping is often required to clarify requirements


              So, we have to
              - document it
              - control its evolution
              - specify it (maybe formalize it)
                                                                          8
N.L. Hsueh, SE-Lab IECS FCU
                                                  Software Engineering


        The requirements engineering process
       Feasibility study
          Find out if the current user needs be satisfied given the
           available technology and budget?
       Requirements analysis
          Find out what system stakeholders require from the
           system
       Requirements definition
          Define the requirements in a form understandable to the
           customer
       Requirements specification
          Define the requirements in detail




                                                                       9
N.L. Hsueh, SE-Lab IECS FCU
                                                       Software Engineering

                          The RE process

   Feasibility          Requirements
     study                analysis
                                       Requir ements
                                         definition
   Feasibility                                               Requirements
     report                                                  specification
                              System
                              models
                                       Definition of
                                       requirements

                        Requirements                        Specification of
                         document                            requirements


                                                                             10
N.L. Hsueh, SE-Lab IECS FCU
                                     Software Engineering




          Requirements Elicitation Techniques




                                                     11
N.L. Hsueh, SE-Lab IECS FCU
                                           Software Engineering




        He who asks a question is a fool for five
        minutes; he who does not ask a question
        remains a fool forever

        Chinese Proverb




                                                           12
N.L. Hsueh, SE-Lab IECS FCU
                                                         Software Engineering

         Requirements Elicitation Techniques

       Two sources of information for the requirements elicitation
        process
          User
          Application domain
       Asking
          Ask users what they expect from the system
          Interview, brainstorm, questionnaire
          Drawback: Over-leading
          Delphi technique
                Information is exchanged in a written form until a consensus
                 is reached




                                                                                13
N.L. Hsueh, SE-Lab IECS FCU
                                                  Software Engineering

                              Conti.

       Task analysis
          High-level tasks can be decomposed into sub-tasks
          E.g.: page 218
       Scenario-based analysis
          Study instances of tasks
          A scenario can be real or artificial
          From scenario to exception
          E.g.: page 219
       Form analysis
          A lot of information about the domain being modeled can
           often be found in various forms being used
          Forms provide us with information about the data objects
           of the domain, their properties, and their interrelations

                                                                       14
N.L. Hsueh, SE-Lab IECS FCU
                                                   Software Engineering

                               Conti.

       Natural language description
          NLD provide a lot of useful information about the domain
           to be modeled
          Provide the analyst with background information to be
           used in conjunction with other elicitation techniques such
           as interviews
          Capture tacit knowledge
          Up-to-date? Validity?
       Derivation from an existing system
          Take the peculiar circumstances of the present situation
           into account
       Prototyping



                                                                        15
N.L. Hsueh, SE-Lab IECS FCU
                                    Software Engineering




         Requirement Specification Techniques




                                                    16
N.L. Hsueh, SE-Lab IECS FCU
                                             Software Engineering




        The analysis model allows a reviewer to
        examine software requirement from three
        different points of view: data, flow, behavior

        R. Pressman




                                                             17
N.L. Hsueh, SE-Lab IECS FCU
                                                   Software Engineering

       Requirement Specification Techniques

       Disadvantages of using NL to be as specification
          Noise
          Silence
          Over-specification
          Contradictions
          Ambiguity
          Forward references
          Wishful thinking




                                                                   18
N.L. Hsueh, SE-Lab IECS FCU
                                                   Software Engineering

                              ER Modeling

       examines data objects independently of processing
       focuses attention on the data domain
       creates a model at the customer’s level of abstraction
       indicates how data objects relate to one another




                                                                   19
N.L. Hsueh, SE-Lab IECS FCU
                                                    Software Engineering

                              Object Entity

       Object
          Sometimes it is described by a set of attributes and that
           will be manipulated within the software
          Each instance of an object can be identified uniquely
          Each plays a necessary role in the system, I.e., the system
           could not function without access to instance of objects
       Typical objects
          external entities (printer, user, sensor)
          Things occurrences or events (e.g., interrupt, alarm)
          roles (e.g., manager, engineer, salesperson)
          organizational units (e.g., division, team)
          Places(e.g., manufacturing floor)
          structures(e.g., employee record)


                                                                         20
N.L. Hsueh, SE-Lab IECS FCU
                                        Software Engineering




           object: automobile   object: Person
           attributes:          attributes:
             make                 birthday
             model                height
             body type            weight
             price                expertise
             options code         country




                                                        21
N.L. Hsueh, SE-Lab IECS FCU
                                                     Software Engineering

                      What is a Relationship?

          relationship —indicates “connectedness”;
          a "fact" that must be "remembered"
          by the system and cannot or is not computed
          or derived
                 several instances of a relationship can exist
                 objects can be related in many different ways


                                  own




                                                                     22
N.L. Hsueh, SE-Lab IECS FCU
                                                           Software Engineering


                          (0, m)
             object1               relationship            object 2
                                                  (1, 1)


              OR                                             attribute



              object1              relationship
                                                           object 2
                          (0, m)                  (1, 1)



                                     own




              Person               relationship
                                                           Automobile

                                                                           23
N.L. Hsueh, SE-Lab IECS FCU
                                                                  Software Engineering

                           The ERD: An Example


                                                       request
         Customer                  places              for service
                       (1,1)                   (1,m)
                                                             (1,1)
           standard                                    generates (1,n)   work
          task table                                                     order
         (1,1)                                                       (1,1)   (1,1)
          selected     work                 (1,w)      consists
            from (1,w) tasks                              of
                                            (1,i)
                               materials                  lists




                                                                                     24
N.L. Hsueh, SE-Lab IECS FCU
                                               Software Engineering

                              The Flow Model

                Every computer-based system is an
                information transform ....



                                 computer
                 input            based        output
                                  system




                                                               25
N.L. Hsueh, SE-Lab IECS FCU
                                              Software Engineering
                        Flow Modeling Notation


                                external entity



                                 process


                                 data flow


                                 data store


                                                              26
N.L. Hsueh, SE-Lab IECS FCU
                                                Software Engineering

                              External Entity


                A producer or consumer of data


              Examples: a person, a device, a sensor

              Another example: computer-based
              system

              Data must always originate somewhere
              and must always be sent to something



                                                                27
N.L. Hsueh, SE-Lab IECS FCU
                                            Software Engineering


                              Process

                 A data transformer (changes input
                 to output)

             Examples: compute taxes, determine area,
             format report, display graph

             Data must always be processed in some
             way to achieve system function




                                                            28
N.L. Hsueh, SE-Lab IECS FCU
                                                  Software Engineering
                               Data Flow



                Data flows through a system, beginning
                as input and be transformed into output.

                        base
                                compute
                                           area
                                triangle
                      height       area




                                                                  29
N.L. Hsueh, SE-Lab IECS FCU
                                                        Software Engineering


                                Data Stores

                      Data is often stored for later use.

                         sensor #
                                                 sensor #, type,
                                     look-up     location, age
                                      sensor
              report required          data
                                                    type,
                                                    location, age
                                sensor number

                                               sensor data




                                                                        30
N.L. Hsueh, SE-Lab IECS FCU
                                                                             Software Engineering


                                      An Example

                                                                                                 Checked and
                     Completed                  Signed       Signed          Send to             signed order
                     order form               order form    order form       supplier               + order
  Or der
                                                                                                  notification
 details +   Complete             Valida te                Record
  blank      order form            order                    order
order form                                                                    Adjust
                                                     Order                   available
                                                                 Signed       budget
                                                     details    order form
                                                                                           Order
                                                                                          amount
                                                                                         + account
                                                                                          details
                                                           Orders             Budget
                                                            file               file




                                                                                                         31
 N.L. Hsueh, SE-Lab IECS FCU
                                                 Software Engineering
                     Data Flow Diagramming:
                            Guidelines

              all icons must be labeled with meaningful names
              the DFD evolves through a number of levels of
               detail
              always begin with a context level diagram (also
               called level 0)
              always show external entities at level 0
              always label data flow arrows
              do not represent procedural logic




                                                                 32
N.L. Hsueh, SE-Lab IECS FCU
                                                   Software Engineering

                    Constructing a DFD — I

               review ERD to isolate data objects and grammatical
                parse to determine “operations)
               determine external entities (producers and
                consumers of data)
               create a level 0 DFD




                                                                     33
N.L. Hsueh, SE-Lab IECS FCU
                                                     Software Engineering


                         Level 0 DFD Example


                        processing
                user      request             requested
                                                video
                                    digital     signal
                                    video                 monitor
                                  processor
               video
              source      NTSC
                       video signal




                                                                     34
N.L. Hsueh, SE-Lab IECS FCU
                                                     Software Engineering
                      Constructing a DFD — II


            write a narrative describing the transform
            parse to determine next level transforms
            “balance” the flow to maintain data flow continuity
            develop a level 1 DFD
            use a 1:5 (approx.) expansion ratio




                                                                     35
N.L. Hsueh, SE-Lab IECS FCU
                                                                  Software Engineering
                     The Data Flow Hierarchy


                              a                      b
                    x                    P                    y       level 0



             a                 c        p2
                     p1
                                                 f

                                                     p4                  b
                           d                                      5
                                   p3        e            g
                 level 1



                                                                                  36
N.L. Hsueh, SE-Lab IECS FCU
                                                     Software Engineering
                         Flow Modeling Notes

              each bubble is refined until it does just one thing
              the expansion ratio decreases as the number of
               levels increase
              most systems require between 3 and 7 levels for
               an adequate flow model




                                                                     37
N.L. Hsueh, SE-Lab IECS FCU
                                         Software Engineering
                         DFDs: A Look Ahead




        analysis model
                                   Maps into
                          design model




                                                         38
N.L. Hsueh, SE-Lab IECS FCU
                                                            Software Engineering
                           The Control Model
               the control flow diagram is "superimposed" on the DFD
               and shows events that control the processes noted in
               the DFD
               control flows—events and control items—are noted by
               dashed arrows

               a vertical bar implies an input to or output from a control
               spec (CSPEC) — a separate specification that
               describes how control is handled

               a dashed arrow entering a vertical bar is an input to the
               CSPEC

               a dashed arrow leaving a process implies a data
               condition (for example, “above pressure”)

               a dashed arrow entering a process implies a control
               input read directly by the process


                                                                             39
N.L. Hsueh, SE-Lab IECS FCU
                                                                Software Engineering


                                                    process


                                     Dataflow between process


                        process


                                  An input (event, message, condition) to CSPEC



                                                                    CSPEC bar



                              A control message to a process



                        process


                                                                                  40
N.L. Hsueh, SE-Lab IECS FCU
                                                                     Software Engineering

       Paper feed status
       (jammed, empty)                Alarm




                    Start/stop      Manage copying

                                                        Produce user displays
              Read operator input




                                                   Perform problem diagnosis

                                    Reload paper

                                              Full
                                                                    Repro fault



                           See CSPEC

                                                                                     41
N.L. Hsueh, SE-Lab IECS FCU
                                            Software Engineering
                 Control Specification (CSPEC)


        The CSPEC can be:
              state transition diagram
              (sequential spec)

              state transition table     combinatorial spec

              decision tables

              activation tables




                                                              42
N.L. Hsueh, SE-Lab IECS FCU
                                                            Software Engineering
                 Guidelines for Building a CSPEC
                list all sensors that are "read" by the software

                list all interrupt conditions

                list all "switches" that are actuated by the operator

                list all data conditions

                recalling the noun-verb parse that was applied to the
                software statement of scope, review all "control items"
                as possible CSPEC inputs/outputs

                describe the behavior of a system by identifying its
                states; identify how each state is reach and defines
                the transitions between states

                focus on possible omissions ... a very common error in
                specifying control, e.g., ask: "Is there any other way I
                can get to this state or exit from it?"

                                                                            43
N.L. Hsueh, SE-Lab IECS FCU
                                           Software Engineering
                Process Specification (PSPEC)

                              bubble



                     PSPEC
                         narrative
                         pseudocode (PDL)
                         equations
                         tables
                         diagrams and/or charts




                                                           44
N.L. Hsueh, SE-Lab IECS FCU
                                                             Software Engineering
                                    Example

                                  Check &
                                  convert
                                  pressure



                   PSPEC
                  If absolute tank pressure > max pressure
                  then
                     set above pressure to “true”;
                  else
                     set above pressure to “false”;
                     begin conversion algorithm x-01a;
                       compute converted pressure;
                     end
                  end if


                                                                             45
N.L. Hsueh, SE-Lab IECS FCU
                                              Software Engineering

                              A Design Note




                      PSPEC         one or more ”components"
                                    in the software design




                                                              46
N.L. Hsueh, SE-Lab IECS FCU
                                                 Software Engineering
                          Creating Mini-Specs




                                 Software
                                 Specification




                                                                 47
N.L. Hsueh, SE-Lab IECS FCU
                                                   Software Engineering
              The Relationship between data and
                        control models
                              Process model

           Data input             DFDs          Data output


                                PSPECs


              Process                         data conditions:
              activators                       occurs when data input a
                              Control model    process results in a control
                                               output
                                  CFDs


                                CSPECs
        Control output                          Control input




                                                                              48
N.L. Hsueh, SE-Lab IECS FCU
                                                Software Engineering

                       Behavioral Modeling


                              events                 behavior

           Outside
                                       Application
            world




                                                                49
N.L. Hsueh, SE-Lab IECS FCU
                                                    Software Engineering

                       The States of a System
               state—a set of observable circum-stances that
                characterizes the behavior of a system at a given
                time
               state transition—the movement from one state to
                another
               event—an occurrence that causes the system to
                exhibit some predictable form of behavior
               action—process that occurs as a consequence of
                making a transition




                                                                    50
N.L. Hsueh, SE-Lab IECS FCU
                                                   Software Engineering
                          Behavioral Modeling


             make a list of the different states of a system (How
              does the system behave?)
             indicate how the system makes a transition from one
              state to another (How does the system change
              state?)
                 indicate event
                 indicate action
             draw a state transition diagram




                                                                     51
N.L. Hsueh, SE-Lab IECS FCU
                                                        Software Engineering
                     State Transition Diagram
                             Notation
   Event                                Initial state               State
       button1&2Pressed                   button2Pressed
                              Blink                          Increment
                              Hours                            Hours


            Transition            button1Pressed


        button1&2Pressed                  button2Pressed
                               Blink                         Increment
                              Minutes                         Minutes


                                  button1Pressed

                                          button2Pressed
        Stop                   Blink                         Increment
      Blinking                Seconds                         Seconds
               button1&2Pressed

                    Final state
                                                                         52
N.L. Hsueh, SE-Lab IECS FCU
                                                         Software Engineering
                      State Transition Diagram
               full and start
         invoke manage-copying reading
                               operator
                              commands
                                                        full
                                                 invoke read-op-input
                                 copies done
                              invoke read-op-input


                 making copies                   reloading paper
                                      empty
                                 invoke reload paper

                      jammed
               invoke problem-diagnosis
                                                     not jammed
                                 problem state    invoke read-op-input




                                                                         53
N.L. Hsueh, SE-Lab IECS FCU
                                            Software Engineering
                         State Generalization




                                                            54
N.L. Hsueh, SE-Lab IECS FCU
                                            Software Engineering

                        State Aggregation




                                                            55
N.L. Hsueh, SE-Lab IECS FCU
                                                  Software Engineering
                  Real-Time Analysis Methods


            each introduces its own notation, but all
               propose an approach for representing control and
                separating it from data
               provide a mechanism for specifying events, states,
                and distributed processing
               begin at the analysis level and work to derive
                processor assignments, tasks and program
                architectures




                                                                     56
N.L. Hsueh, SE-Lab IECS FCU
                                             Software Engineering
                         The Data Dictionary

       a quasi-formal grammar for describing the content
       of data that the software will process and create

       a notation for describing control data and the
       values that control data can take, e.g., "on," or "off"

       a repository that also contains "where-used" / "how
       used" information

       a notation that can be represented manually, but is
       best developed using CASE tools



                                                                 57
N.L. Hsueh, SE-Lab IECS FCU
                                                   Software Engineering
                    Building a Data Dictionary
  Name:             the primary name of the composite data item

  Aliases:          other names for the data item

  Where used: data transforms (processes) that use the
              composite data item

  How used:         the role of the data item (input, output,
                    temporary storage, etc.

  Description:      a notation for representing content (presented
                    on next slide)

  Format:           specific information about data types, pre-set
                    values (if known)


                                                                     58
N.L. Hsueh, SE-Lab IECS FCU
                                                    Software Engineering
                      Data Dictionary Notation
                   Notation             Meaning

                          =          is composed of

                          +               and

                      [       ]         either-or

                              n
                      { }            n repetitions of

                     ( ... )          optional data

                 * ... text ...*   delimits a comment
                                                                    59
N.L. Hsueh, SE-Lab IECS FCU
                                                                                   Software Engineering
                    Data Dictionary Example

                                              integrated
                        telephone number         office                 system output
                                                phone
                                                system



                    Build the requirements dictionary:
                         Name:             telephone number

                         Aliases:          phone number, number

                         Where/How         read-phone-number (input)
                         used:             display-phone-number (output)
                                           analyze-long-distance-calls (input)

                         Description:      telephone no. = [ local extension | outside no. | 0 ]
                                           outsid e no. = 9 + [ servic e code | domestic no. ]
                                           servic e code = [ 211 | 411 | 611 | 911 ]
                                           domestic no. = ( ( 0 ) + area code ) + local number
                                           area code = *three numeral designator*

                         Format:           alphanumeric data


                                                                                                   60
N.L. Hsueh, SE-Lab IECS FCU
                                                              Software Engineering




                                                              Process
          Data Object                                         specification
          description                                         (PSPEC)
                         ERD                       DFD

                  Data
                                 Data dictionary
                                                      Function

                                       STD


                                  Behavior
                              Control Specification (CSPEC)


                                                                              61
N.L. Hsueh, SE-Lab IECS FCU
                                       Software Engineering




                     Requirement Document




                                                       62
N.L. Hsueh, SE-Lab IECS FCU
                                        Software Engineering




        Everyone knew exactly what had to be done
        until someone wrote it down!

        R. Pressman




                                                        63
N.L. Hsueh, SE-Lab IECS FCU
                                                    Software Engineering
                        The requirements
                           document

       The requirements document is the official statement of what is
        required of the system developers
       Should include both a definition and a specification of
        requirements
       It is NOT a design document. As far as possible, it should set
        of WHAT the system should do rather than HOW it should do
        it
       Correct, unambiguous, complete, consistent, ranked,
        verifiable, modifiable, traceable




                                                                         64
N.L. Hsueh, SE-Lab IECS FCU
                                               Software Engineering
                     Specification Guidelines

         use a layered format that provides increasing detail
         as the "layers" deepen

         use consistent graphical notation and apply textual
         terms consistently (stay away from aliases)

         be sure to define all acronyms

         be sure to include a table of contents; ideally,
         include an index and/or a glossary

         write in a simple, unambiguous style (see "editing
         suggestions" on the following pages)

         always put yourself in the reader's position, "W ould
         I be able to understand this if I wasn't intimately
         familiar with the system?"
                                                                 65
N.L. Hsueh, SE-Lab IECS FCU
                                                            Software Engineering
                        Editing Suggestions

     Be on the lookout for persuasive connectors, ask why?
        keys: certainly, therefore, clearly, obviously, it follows that ...

     Watch out for vague terms
       keys: some, sometimes, often, usually,ordinarily, most, mostly ...

     When lists are given, but not completed, be sure all items are understood
       keys: etc., and so forth, and so on, such as

     Be sure stated ranges don't contain unstated assumptions
        e.g., Valid codes range from 10 to 100. Integer? Real? Hex?

     Beware of vague verbs such as handled, rejected, processed, ...
     Beware "passive voice" statements
       e.g.,The parameters are initialized. By what?

     Beware "dangling" pronouns
         e.g.,The I/O module communicated with the data validation module and
     its control flag is set. Whose control flag?

                                                                                 66
N.L. Hsueh, SE-Lab IECS FCU
                                                        Software Engineering

                   Specification Guidelines

        When a term is explicitly defined in one place, try
        substituting the definition forother occurrences of the term

        When a structure is described in words, draw a picture

        When a structure is described with a picture, try to redraw
        the picture to emphasize different elements of the structure
        When symbolic equations are used, try expressing their
        meaning in words
        When a calculation is specified, work at least two
        examples

        Look for statements that imply certainty, then ask for proof
            keys; always, every, all, none, never
        Search behind certainty statements—be sure restrictions
        or limitations are realistic

                                                                        67
N.L. Hsueh, SE-Lab IECS FCU
                                                    Software Engineering
                   Requirements document
                          structure

       Introduction
           Describe need for the system and how it fits with business
            objectives
       Glossary
           Define technical terms used
       System models
           Define    models showing system components and
            relationships
       Functional requirements definition
           Describe the services to be provided




                                                                         68
N.L. Hsueh, SE-Lab IECS FCU
                                                Software Engineering

                              Conti.

       Non-functional requirements definition
           Define constraints on the system and the development
            process
       System evolution
           Define fundamental assumptions on which the system is
            based and anticipated changes
       Requirements specification
           Detailed specification of functional requirements
       Appendices
           System hardware platform description
           Database requirements (as an ER model perhaps)
       Index


                                                                    69
N.L. Hsueh, SE-Lab IECS FCU
                                                             Software Engineering




       IEEE Standard 830
           Does not give a rigid form for the requirements
            specification

                    1.   Introduction
                         1.1 Purpose
                         1.2 Scope
                         1.3 Definitions, acronyms and abbreviations
                         1.4 References
                         1.5 Overview
                    2.   Overall description
                         2.1 product perspective
                         2.2 product functions
                         2.3 user characteristics
                         2.4 Constraints
                         2.5 Assumptions and dependencies
                         2.6 Requirements subsets
                    3.   Specific Requirements

                                                                             70
N.L. Hsueh, SE-Lab IECS FCU
                                                               Software Engineering




       Refinement of specific requirements along the dimension of
        “user classes”
                    3.   Specific Requirements
                         3.1 external interface requirements
                               3.1.1 user interface
                               3.1.2 hardware interfaces
                               3.1.3 software interfaces
                               3.1.4 communications interfaces
                         3.2 functional requirements
                               3.2.1 user class 1
                                          3.2.1.1 functional requirement 1.1
                                          3.2.1.1 functional requirement 1.2
                                          3.2.1.1 functional requirement 1.3
   See Figure 9.8              3.2.1 user class 2
                                          ---
                         3.3 performance requirements
                         3.4 Design constraints
                         3.5 software system attributes
                         3.6 other requirements
                                                                               71
N.L. Hsueh, SE-Lab IECS FCU
                                                          Software Engineering

                 Capturing Design Rational



                                    Argument



              issue                  supports


                      Response_to
                                                Take_by
                                    position               people




                       Figure 9.9 Network Representation

                                                                          72
N.L. Hsueh, SE-Lab IECS FCU
                                        Software Engineering




                    Requirement Validation




                                                        73
N.L. Hsueh, SE-Lab IECS FCU
                                            Software Engineering



        Developers may build and test against
        specification but users accept or reject against
        current and actual operational realities

        Bernard Boar




        Facts do not cease to exist because they are
        ignored

        Aldous Huxley

                                                            74
N.L. Hsueh, SE-Lab IECS FCU
                                                   Software Engineering

                   Requirements validation

       Concerned with demonstrating that the requirements define
        the system that the customer really wants
       Requirements error costs are high so validation is very
        important
           Fixing a requirements error after delivery may cost up to
            100 times the cost of fixing an implementation error
       Prototyping is an important technique of requirements
        validation




                                                                        75
N.L. Hsueh, SE-Lab IECS FCU
                                                     Software Engineering

                   Requirements checking

       Validity.
          Does the system provide the functions which best support the
            customer’s needs?
       Consistency.
          Are there any requirements conflicts?
       Completeness.
          Are all functions required by the customer included?
       Realism.
          Can the requirements be implemented given available budget
            and technology
       Verifiability.
          Is the requirement realistically testable?
       Comprehensibility.
          Is the requirement properly understood?
       Tractability.
          Is the origin of the requirement clearly stated?

                                                                          76
N.L. Hsueh, SE-Lab IECS FCU
                                                 Software Engineering




       Regular reviews should be held while the requirements
        definition is being formulated
           Good communications between developers, customers
            and users can resolve problems at an early stage
           Both client and contractor staff should be involved in
            reviews
       Reviews may be formal (with completed documents) or
        informal




                                                                     77
N.L. Hsueh, SE-Lab IECS FCU
                                              Software Engineering

                   Automated consistency
                         checking


       Requirements                             Requirements
   in a formal language                         problem report



       Requirements                             Requirements
         processor                                analyser


                              Requir ements
                                database



                                                                 78
N.L. Hsueh, SE-Lab IECS FCU
                                        Software Engineering




                    Requirements Evolution




                                                        79
N.L. Hsueh, SE-Lab IECS FCU
                                           Software Engineering



        Any change, event a change for the better, is
        always accompanied by drawbacks and
        discomforts

        Arnold Bennett




        The art of progress is to preserve order amid
        change and to preserve change amid order

        Alfred North Whitehead

                                                           80
N.L. Hsueh, SE-Lab IECS FCU
                                                   Software Engineering

                   Requirements Evolution

       Requirements always evolve as a better understanding of
        user needs is developed and as the organization’s objectives
        change
       It is essential to plan for change in the requirements as the
        system is being developed and used




                                                                        81
N.L. Hsueh, SE-Lab IECS FCU
                                         Software Engineering

                   Requirements evolution


       Initial                       Changed
    understanding                  understanding
     of problem                     of problem



        Initial                           Changed
     requirements                       requir ements


                                                    Time
                                                         82
N.L. Hsueh, SE-Lab IECS FCU
                                                     Software Engineering

                     Requirements classes

       Enduring requirements. Stable requirements derived from the
        core activity of the customer organization. E.g. a hospital will
        always have doctors, nurses, etc. May be derived from
        domain models
       Volatile requirements. Requirements which change during
        development or when the system is in use. In a hospital,
        requirements derived from health-care policy




                                                                           83
N.L. Hsueh, SE-Lab IECS FCU
                                                 Software Engineering

                     Volatile requirements.

       Mutable requirements
          Requirements      that change due to the system’s
           environment
       Emergent requirements
          Requirements that emerge as understanding of the system
           develops
       Consequential requirements
          Requirements that result from the introduction of the
           computer system
       Compatibility requirements
          Requirements      that depend on other systems or
           organizational business processes



                                                                     84
N.L. Hsueh, SE-Lab IECS FCU
                                                Software Engineering
                    Requirements document
                           changes

       The requirements document should be organized so that
        requirements changes can be made without extensive
        rewriting
       External references should be minimized and the document
        sections should be as modular as possible
       Changes are easiest when the document is electronic.
           Lack of standards for electronic documents make this
            difficult (document exchange problem)




                                                                   85
N.L. Hsueh, SE-Lab IECS FCU
                                                              Software Engineering

                           Controlled evolution


                                                                 Requirements
                                                                    change



  Requirements        Requirements             Requirements              Requirements
  document V1            change                document V1               document V2



     System                   System              System                   System
implementation V1        implementation V2   implementation V1        implementation V2

          Requirements and system                       Requirements and system
                inconsistent                                   consistent




                                                                                        86
N.L. Hsueh, SE-Lab IECS FCU
                                                  Software Engineering

                              Key points

       It is very difficult to formulate a complete and consistent
        requirements specification
       The requirements document is a description for customers
        and developers
       Requirements errors are usually very expensive to correct
        after system delivery
       Reviews involving client and contractor staff are used to
        validate the system requirements
       Stable requirements are related to core activities of the
        customer for the software
       Volatile requirements are dependent on the context of use of
        the system




                                                                       87
N.L. Hsueh, SE-Lab IECS FCU
                                          Software Engineering




         The problems is not that there are problems.
         The problem is expecting otherwise and
         thinking that having problems is a problem

         Theodore Rubin




                                                          88
N.L. Hsueh, SE-Lab IECS FCU

				
About if any file u wil find copyright contact me it will be remove in 3 to 4 buisnees days. add me on sanjaydudeja007@gmail.com or visit http://www.ohotech.com/