Requirements Engineering User Requirements

Document Sample
Requirements Engineering User Requirements Powered By Docstoc
					                                                                                               Requirements Engineering
      IF2261 Software Engineering
                                                                                      helps software engineers better understand
                                                                                      the problems they are trying to solve
       Requirement Engineering                                                        produce a written understanding of the
                                                                                      customer's problem.
                                                                                      begins during the software engineering
         Program Studi Teknik Informatika                                             communication activity and continues into the
                    STEI ITB                                                          modeling activity
                                                                                     * SEPA 6th ed, Roger S. Pressman


                  IF-ITB/YW/Revisi: Februari 2006                           Page 1                                      IF-ITB/YW/Revisi: Februari 2006                           Page 2
                  IF2261 Requirement Engineering                                                                        IF2261 Requirement Engineering




        What is a Requirement ?                                                                           Types of Requirement
It may range from a high-level abstract statement of                                   User requirements
a service or of a system constraint to a detailed                                           Statements in natural language plus diagrams of the
                                                                                            services the system provides and its operational
mathematical functional specification.                                                      constraints. Written for customers.
This is inevitable as requirements may serve a dual                                    System requirements
function                                                                                    A structured document setting out detailed descriptions of
  May be the basis for a bid for a contract - therefore must                                the system’s functions, services and operational
  be open to interpretation;                                                                constraints. Defines what should be implemented so may
                                                                                            be part of a contract between client and contractor.
  May be the basis for the contract itself - therefore must be
  defined in detail;
  Both these statements may be called requirements.
                                   * Software Engineering 7th ed, Ian Sommerville                                                        * Software Engineering 7th ed, Ian Sommerville


                  IF-ITB/YW/Revisi: Februari 2006                           Page 3                                      IF-ITB/YW/Revisi: Februari 2006                           Page 4
                  IF2261 Requirement Engineering                                                                        IF2261 Requirement Engineering




    Definitions and Specifications
                                                                                                           User Requirements
                                                                                      Should describe functional and non-functional
                                                                                      requirements in such a way that they are
                                                                                      understandable by system users who don’t
                                                                                      have detailed technical knowledge.
                                                                                      User requirements are defined using natural
                                                                                      language, tables and diagrams as these can
                                                                                      be understood by all users.

                                                                                                                                         * Software Engineering 7th ed, Ian Sommerville
                                   * Software Engineering 7th ed, Ian Sommerville
                  IF-ITB/YW/Revisi: Februari 2006                           Page 5                                      IF-ITB/YW/Revisi: Februari 2006                           Page 6
                  IF2261 Requirement Engineering                                                                        IF2261 Requirement Engineering
Problems with natural language                                                                       System Requirements
                                                                                              More detailed specifications of system functions,
Lack of clarity
                                                                                              services and constraints than user requirements.
   Precision is difficult without making the document difficult
   to read.                                                                                   They are intended to be a basis for designing the
                                                                                              system.
Requirements confusion
                                                                                              They may be incorporated into the system contract.
   Functional and non-functional requirements tend to be
   mixed-up.                                                                                  System requirements may be defined or illustrated
                                                                                              using system models
Requirements amalgamation
   Several different requirements may be expressed together.


                                      * Software Engineering 7th ed, Ian Sommerville                                                     * Software Engineering 7th ed, Ian Sommerville


                     IF-ITB/YW/Revisi: Februari 2006                                Page 7                          IF-ITB/YW/Revisi: Februari 2006                               Page 8
                     IF2261 Requirement Engineering                                                                 IF2261 Requirement Engineering




Functional and Non-Functional Requirements                                                         Functional Requirements
Functional requirements
   Statements of services the system should provide, how the                                  Describe functionality or system services.
   system should react to particular inputs and how the                                       Depend on the type of software, expected users and
   system should behave in particular situations.                                             the type of system where the software is used.
Non-functional requirements
                                                                                              Functional user requirements may be high-level
   constraints on the services or functions offered by the
   system such as timing constraints, constraints on the                                      statements of what the system should do but
   development process, standards, etc.                                                       functional system requirements should describe the
Domain requirements                                                                           system services in detail.
   Requirements that come from the application domain of
   the system and that reflect characteristics of that domain.
                                      * Software Engineering 7th ed, Ian Sommerville                                                     * Software Engineering 7th ed, Ian Sommerville


                     IF-ITB/YW/Revisi: Februari 2006                                Page 9                          IF-ITB/YW/Revisi: Februari 2006                               Page 10
                     IF2261 Requirement Engineering                                                                 IF2261 Requirement Engineering




Non-functional Requirements Examples                                                                 Requirements Measures
                                                                                                      Property              Measure
Product requirement                                                                                   Speed                 Processed transactions/second
                                                                                                                            User/Event response time
 8.1 The user interface for LIBSYS shall be implemented as simple HTML                                                      Screen refresh time
     without frames or Java applets.
                                                                                                      Size                  M Bytes
Organisational requirement                                                                                                  Number of ROM chips
                                                                                                      Ease of use           Training time
 9.3.2 The system development process and deliverable documents shall                                                       Number of help frames
     conform to the process and deliverables defined in XYZCo-SP-
                                                                                                      Reliability           Mean time to failure
     STAN-95.                                                                                                               Probability of unavailability
                                                                                                                            Rate of failure occurrence
External requirement                                                                                                        Availability
 7.6.5 The system shall not disclose any personal information about                                   Robustness            Time to restart after failure
                                                                                                                            Percentage of events causing failure
     customers apart from their name and reference number to the                                                            Probability of data corruption on failure
     operators of the system.
                                                                                                      Portability           Percentage of target dependent statements
                                                                                                                            Number of target systems

                                      * Software Engineering   7th   ed, Ian Sommerville
                                                                                                                                         * Software Engineering 7th ed, Ian Sommerville

                     IF-ITB/YW/Revisi: Februari 2006                                Page 11                         IF-ITB/YW/Revisi: Februari 2006                               Page 12
                     IF2261 Requirement Engineering                                                                 IF2261 Requirement Engineering
     Requirements Interaction                                                                 Domain Requirements
Conflicts between different non-functional
requirements are common in complex systems.                                          Derived from the application domain and describe
Spacecraft system                                                                    system characteristics and features that reflect the
    To minimise weight, the number of separate chips in the                          domain.
    system should be minimised.                                                      Domain requirements be new functional
    To minimise power consumption, lower power chips                                 requirements, constraints on existing requirements
    should be used.
                                                                                     or define specific computations.
    However, using low power chips may mean that more
    chips have to be used. Which is the most critical                                If domain requirements are not satisfied, the system
    requirement?                                                                     may be unworkable.

                                  * Software Engineering 7th ed, Ian Sommerville                                          * Software Engineering 7th ed, Ian Sommerville


                 IF-ITB/YW/Revisi: Februari 2006                           Page 13                       IF-ITB/YW/Revisi: Februari 2006                           Page 14
                 IF2261 Requirement Engineering                                                          IF2261 Requirement Engineering




Domain Requirements Problems                                                         Requirements Completeness and Consistency
                                                                                      In principle, requirements should be both complete and
Understandability                                                                     consistent.
  Requirements are expressed in the language of the                                   Complete
  application domain;                                                                      They should include descriptions of all facilities required.
  This is often not understood by software engineers                                  Consistent
  developing the system.
                                                                                           There should be no conflicts or contradictions in the
Implicitness                                                                               descriptions of the system facilities.
  Domain specialists understand the area so well that they                            In practice, it is impossible to produce a complete and
  do not think of making the domain requirements explicit.                            consistent requirements document.


                                  * Software Engineering 7th ed, Ian Sommerville                                          * Software Engineering 7th ed, Ian Sommerville


                 IF-ITB/YW/Revisi: Februari 2006                           Page 15                       IF-ITB/YW/Revisi: Februari 2006                           Page 16
                 IF2261 Requirement Engineering                                                          IF2261 Requirement Engineering




    Requirements Imprecision
Problems arise when requirements are not precisely
stated.
Ambiguous requirements may be interpreted in
different ways by developers and users.
Consider the term ‘appropriate viewers’
  User intention - special purpose viewer for each different
  document type;
  Developer interpretation - Provide a text viewer that shows
  the contents of the document.

                                  * Software Engineering 7th ed, Ian Sommerville


                 IF-ITB/YW/Revisi: Februari 2006                           Page 17                       IF-ITB/YW/Revisi: Februari 2006                           Page 18
                 IF2261 Requirement Engineering                                                          IF2261 Requirement Engineering
Guidelines for Writing Requirements                                                                          Problems with NL specification
                                                                                                             Ambiguity
 Invent a standard format and use it for all
                                                                                                                 The readers and writers of the requirement must
 requirements.                                                                                                   interpret the same words in the same way. NL is
 Use language in a consistent way. Use shall for                                                                 naturally ambiguous so this is very difficult.
 mandatory requirements, should for desirable                                                                Over-flexibility
 requirements.                                                                                                   The same thing may be said in a number of different
                                                                                                                 ways in the specification.
 Use text highlighting to identify key parts of the
                                                                                                             Lack of modularisation
 requirement.
                                                                                                                 NL structures are inadequate to structure system
 Avoid the use of computer jargon.                                                                               requirements.

                                                       * Software Engineering 7th ed, Ian Sommerville                                            * Software Engineering 7th ed, Ian Sommerville


                                IF-ITB/YW/Revisi: Februari 2006                                 Page 19                         IF-ITB/YW/Revisi: Februari 2006                           Page 20
                                IF2261 Requirement Engineering                                                                  IF2261 Requirement Engineering




    Alternatives to NL specification                                                                          The Requirements Document
Notation             Description
                                                                                                            The requirements document is the official statement
Structured natural   This approach depends on defining standard forms or templates to express the
language             requirements specification.                                                            of what is required of the system developers.
Design               This approach uses a language like a programming language but with more abstract
description          features to specify the requirements by defining an operational model of the system.   Should include both a definition of user requirements
language s           This approach is not now widely used although it can be useful for interface
                     specifications.
                                                                                                            and a specification of the system requirements.
Graphical            A graphical language, supplemented by text annotations is used to define the           It is NOT a design document. As far as possible, it
notations            functional requirements for the system. An early exa mple of such a graphical
                     language was SADT. Now, use-case descriptions and sequence d iagrams are               should set of WHAT the system should do rather
                     commonly used .
                                                                                                            than HOW it should do it
Mathematical         These are notations based on mathematical concep ts such as finite-state machines or
specifications       sets. These unambiguous specifications reduce the arguments between customer and
                     contractor about system functionality. However, most customers don’t understand
                     formal specifications and are reluctant to accept it as a system contract.


                                                       * Software Engineering 7th ed, Ian Sommerville                                            * Software Engineering 7th ed, Ian Sommerville


                                IF-ITB/YW/Revisi: Februari 2006                                 Page 21                         IF-ITB/YW/Revisi: Februari 2006                           Page 22
                                IF2261 Requirement Engineering                                                                  IF2261 Requirement Engineering




 Users of a Requirements Document
                                                                                                              IEEE Requirements Standard
                                                                                                            Defines a generic structure for a requirements
                                                                                                            document that must be instantiated for each
                                                                                                            specific system.
                                                                                                              Introduction.
                                                                                                              General description.
                                                                                                              Specific requirements.
                                                                                                              Appendices.
                                                                                                              Index.
                                                       * Software Engineering 7th ed, Ian Sommerville                                            * Software Engineering 7th ed, Ian Sommerville


                                IF-ITB/YW/Revisi: Februari 2006                                 Page 23                         IF-ITB/YW/Revisi: Februari 2006                           Page 24
                                IF2261 Requirement Engineering                                                                  IF2261 Requirement Engineering
Requirements Document Structure
                     Preface
                     Introduction
                     Glossary
                     User requirements definition
                     System architecture
                     System requirements specification
                     System models
                     System evolution
                     Appendices
                     Index
                                                    * Software Engineering 7th ed, Ian Sommerville


                                   IF-ITB/YW/Revisi: Februari 2006                           Page 25                                      IF-ITB/YW/Revisi: Februari 2006   Page 26
                                   IF2261 Requirement Engineering                                                                         IF2261 Requirement Engineering




           Requirement Engineering Tasks                                                                 Initiating Requirements Engineering Process
 Inception                                                                                               Identify stakeholders
       software engineers use context-free questions to establish a basic understanding of the
       problem, the people who want a solution, the nature of the solution, and the
       effectiveness of the collaboration between customers and developers                               Recognize the existence of multiple stakeholder
 Elicitation                                                                                             viewpoints
       find out from customers what the product objectives are, what is to be done, how the
       product fits into business needs, and how the product is used on a day to day basis               Work toward collaboration among stakeholders
 Elaboration
       focuses on developing a refined technical model of software functions, features, and              These context-free questions focus on customer,
       constraints using the information obtained during inception and elicitation                       stakeholders, overall goals, and benefits of the system
 Negotiation
       requirements are categorized and organized into subsets, relations among requirements                  Who is behind the request for work?
       identified, requirements reviewed for correctness, requirements prioritized based on
       customer needs                                                                                         Who will use the solution?
 Specification                                                                                                What will be the economic benefit of a successful solution?
       written work products produced describing the function, performance, and development
       constraints for a computer-based system                                                                Is there another source for the solution needed?
 Requirements validation
       formal technical reviews used to examine the specification work products to ensure
       requirement quality and that all work products conform to agreed upon standards for the
       process, project, and products                                                                  * SEPA 6th ed, Roger S. Pressman
                                                                   * SEPA 6th ed, Roger S. Pressman

                                   IF-ITB/YW/Revisi: Februari 2006                           Page 27                                      IF-ITB/YW/Revisi: Februari 2006   Page 28
                                   IF2261 Requirement Engineering                                                                         IF2261 Requirement Engineering




  Initiating Requirements Engineering Process                                                                                  Eliciting Requirements
  The next set of questions enable developer to better
  understand the problem and the customer's perceptions of the                                          Collaborative requirements gathering
  solution                                                                                                    Meetings attended by both developers and customers
       How would you characterize good output form a successful solution?
       What problem(s) will this solution address?
                                                                                                              Rules for preparation and participation are established
       Can you describe the business environment in which the solution will                                   Flexible agenda is used
       be used?
       Will special performance constraints affect the way the solution is                                    Facilitator controls the meeting
       approached?                                                                                            Definition mechanism (e.g., stickers, flip sheets, electronic
  The final set of questions focuses on communication                                                         bulletin board) used to gauge group consensus
  effectiveness
       Are you the best person to give "official" answers to these questions?                                 Goal is to identify the problem, propose solution elements,
       Are my questions relevant to your problem? Am I asking too many                                        negotiate approaches, and specify preliminary set of
       questions? Can anyone else provide additional information? Should I
       be asking you anything else?                                                                           solutions requirements
* SEPA 6th ed, Roger S. Pressman                                                                       * SEPA 6th ed, Roger S. Pressman


                                   IF-ITB/YW/Revisi: Februari 2006                           Page 29                                      IF-ITB/YW/Revisi: Februari 2006   Page 30
                                   IF2261 Requirement Engineering                                                                         IF2261 Requirement Engineering
                        Eliciting Requirements                                                          Elicitation Work Products
 Quality function deployment (QFD)                                                      Statement of need and feasibility
       Identifies three types of requirements (normal, expected, exciting)              Bounded statement of scope for system or product
       In customer meetings function deployment is used to determine                    List of stakeholders involved in requirements elicitation
       value of each function that is required for the system
       Information deployment identifies both data objects and events that              Description of system's technical environment
       the system must consume or produce (these are linked to functions)               List of requirements organized by function and applicable
       Task deployment examines the system behavior in the context of its               domain constraints
       environment
       Value analysis is conducted to determine relative priority of each
                                                                                        Set of usage scenarios (use-cases) that provide use insight
       requirement generated by the deployment activities                               into operation of deployed system
 User-scenarios                                                                         Prototypes developed to better understand requirements
       Also known as use-cases, describe how the system will be used
       Developers and users create a set of usage threads for the system to
       be constructed
* SEPA 6th ed, Roger S. Pressman                                                       * SEPA 6th ed, Roger S. Pressman


                                   IF-ITB/YW/Revisi: Februari 2006         Page 31                                        IF-ITB/YW/Revisi: Februari 2006                           Page 32
                                   IF2261 Requirement Engineering                                                         IF2261 Requirement Engineering




               Requirements Elaboration                                                                   Negotiating Requirements
   Developing Use-Cases                                                                 Negotiation activities
        Each use-case tells stylized story about how end-users interact with                 Identification of system key stakeholders
        the system under a specific set of circumstances                                     Determination of stakeholders' "win conditions"
   Analysis Model                                                                            Negotiate to reconcile stakeholders' win conditions into "win-win" result
                                                                                             for all stakeholders (including developers)
        Intent is to provide descriptions of required information, functional, and
        behavioral domains for computer-based systems                                   Key points
        Analysis Model Elements                                                              It's not a competition
             Scenario-based elements (describe system from user perspective)                 Map out a strategy
             Class-based elements (relationships among objects manipulated by actors         Listen actively
             and their attributes)
                                                                                             Focus on other party's interests
             Behavioral elements (depict system and class behavior as states and
             transitions between states)                                                     Don't let it get personal
             Flow-oriented elements (shows how information flows through the system          Be creative
             and is transformed by the system functions)                                     Be ready to commit
* SEPA 6th ed, Roger S. Pressman                                                                                                                          * SEPA 6th ed, Roger S. Pressman


                                   IF-ITB/YW/Revisi: Februari 2006         Page 33                                        IF-ITB/YW/Revisi: Februari 2006                           Page 34
                                   IF2261 Requirement Engineering                                                         IF2261 Requirement 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.




                                                                                                                                           * Software Engineering 7th ed, Ian Sommerville


                                   IF-ITB/YW/Revisi: Februari 2006         Page 35                                        IF-ITB/YW/Revisi: Februari 2006                           Page 36
                                   IF2261 Requirement Engineering                                                         IF2261 Requirement Engineering
               Requirements Checking                                                                      Requirements Validation Techniques
 Validity. Does the system provide the functions
                                                                                                            Requirements reviews
 which best support the customer’s needs?                                                                        Systematic manual analysis of the requirements.
 Consistency. Are there any requirements conflicts?                                                         Prototyping
 Completeness. Are all functions required by the                                                                 Using an executable model of the system to check
 customer included?                                                                                              requirements.
 Realism. Can the requirements be implemented                                                               Test-case generation
 given available budget and technology                                                                           Developing tests for requirements to check
 Verifiability. Can the requirements be checked?                                                                 testability.
                                                    * Software Engineering 7th ed, Ian Sommerville                                                            * Software Engineering 7th ed, Ian Sommerville


                                   IF-ITB/YW/Revisi: Februari 2006                           Page 37                                         IF-ITB/YW/Revisi: Februari 2006                           Page 38
                                   IF2261 Requirement Engineering                                                                            IF2261 Requirement Engineering




                       Requirement Review                                                                          Requirements Management
  Is each requirement consistent with overall project or system objective?
  Are all requirements specified at the appropriate level off abstraction?
  Is each requirement essential to system objective or is it an add-on                                     help project team to identify, control, and track
  feature?
  Is each requirement bounded and unambiguous?
                                                                                                           requirements and changes as project
  Do you know the source for each requirement?                                                             proceeds
  Do requirements conflict with one another?
  Is the requirement achievable in the proposed technical environment for                                  many of these activities are identical to the
  the system or product?
  Is each requirement testable?                                                                            software configuration management (SCM)
  Does the requirements model reflect the information, function, and
  behavior of the system to be built?
                                                                                                           process
  Has the requirements model been partitioned in a way that exposes more
  detailed system information progressively?
  Have all the requirements patterns been properly validated and are they
  consistent with customer requirements?                                                                  * SEPA 6th ed, Roger S. Pressman
                                                                       * SEPA 6th ed, Roger S. Pressman

                                   IF-ITB/YW/Revisi: Februari 2006                           Page 39                                         IF-ITB/YW/Revisi: Februari 2006                           Page 40
                                   IF2261 Requirement Engineering                                                                            IF2261 Requirement Engineering




         Requirements Management                                                                                           Requirements Change
 Process:                                                                                                  The priority of requirements from different viewpoints
       requirements are identified,                                                                        changes during the development process.
       tagged with a unique identifier and
                                                                                                           System customers may specify requirements from a
       classified by type (functional, data, behavioral, interface, or
       output)
                                                                                                           business perspective that conflict with end-user
                                                                                                           requirements.
 Tools:
                                                                                                           The business and technical environment of the
       Traceability tables
            developed and updated any time a requirement is modified
                                                                                                           system changes during its development.
       Database systems
            invaluable in helping software teams track requirement changes
* SEPA 6th ed, Roger S. Pressman                                                                                                                              * Software Engineering 7th ed, Ian Sommerville


                                   IF-ITB/YW/Revisi: Februari 2006                           Page 41                                         IF-ITB/YW/Revisi: Februari 2006                           Page 42
                                   IF2261 Requirement Engineering                                                                            IF2261 Requirement Engineering
          Requirements Classification                                                                              CASE Tool Support
 Requirement                                       Description                                           Requirements storage
    Type
Mutable         Requirements that change because of changes to the environment in which the                Requirements should be managed in a secure, managed
requirements    organisation is operating. For example, in hospital systems, the funding of patient
                care may change and thus require different treatment information to be collected.
                                                                                                           data store.
Emergent
requirements
                Requirements that emerge as the customer's understanding of the system develops
                during the system development. The design process may reveal new emergent
                                                                                                         Change management
                requirements.                                                                              The process of change management is a workflow process
Consequential
requirements
                Requirements that result from the introduction of the computer system. Introducing
                the computer system may change the organisations processes and open up new ways
                                                                                                           whose stages can be defined and information flow
                of working which generate new system requirements                                          between these stages partially automated.
Compatibility   Requirements that depend on the particular systems or b usiness processes within an
requirements    organisation. As these change, the compatibility requirements on the commissioned        Traceability management
                or delivered system may also have to evolve.
                                                                                                           Automated retrieval of the links between requirements.

                                                     * Software Engineering 7th ed, Ian Sommerville                                        * Software Engineering 7th ed, Ian Sommerville


                              IF-ITB/YW/Revisi: Februari 2006                                  Page 43                    IF-ITB/YW/Revisi: Februari 2006                           Page 44
                              IF2261 Requirement Engineering                                                              IF2261 Requirement Engineering




Requirements Change Management
Should apply to all proposed changes to the
requirements.
Principal stages
     Problem analysis. Discuss requirements problem and
     propose change;
     Change analysis and costing. Assess effects of change on
     other requirements;
     Change implementation. Modify requirements document
     and other documents to reflect change.

                                                     * Software Engineering 7th ed, Ian Sommerville


                              IF-ITB/YW/Revisi: Februari 2006                                  Page 45
                              IF2261 Requirement Engineering