Docstoc

Requirements - Software Engineering Laboratory

Document Sample
Requirements - Software Engineering Laboratory Powered By Docstoc
					ECE 355: Software
  Engineering
  CHAPTER 4
   Unit 3 (Part 1)


                 Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                Object-Oriented Software Engineering: Using UML, Patterns, and Java
              Course outline

• Unit 1: Software Engineering Basics
• Unit 2: Process Models and Software Life Cycles
 Unit 3: Software Requirements
• Unit 4: Unified Modeling Language (UML)
• Unit 5: Design Basics and Software Architecture
• Unit 6: OO Analysis and Design
• Unit 7: Design Patterns
• Unit 8: Testing and Reliability
• Unit 9: Software Engineering Management and
  Economics

                                  Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                                 Object-Oriented Software Engineering: Using UML, Patterns, and Java
            Course outline
• Software Engineering Basics
• Process Models
Software Requirements
• Unified Modeling Language (UML)
• Design Process
• OO Design
• Design Patterns
• Testing and Reliability
• Software Engineering Economics


                             Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                            Object-Oriented Software Engineering: Using UML, Patterns, and Java
    Requirements Engineering

• a systematic approach to eliciting, organizing,
  and documenting the requirement of the system,
  and a process that establishes and maintains
  agreement between the customer and the
  project team on the changing requirements of
  the system. (Leffingwell & Widrig 1999)




                               Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                              Object-Oriented Software Engineering: Using UML, Patterns, and Java
 Requirements Engineering




Idea of a new    Requirements               Requirements
product          development                specification
(to solve some   (the process of            (the document that
problem in the   creating the               describes what
real world)      requirements               has to be built,
                 spec)                      not how)
                                    Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                                   Object-Oriented Software Engineering: Using UML, Patterns, and Java
Why software projects fail?




                  Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                 Object-Oriented Software Engineering: Using UML, Patterns, and Java
Communication problems...




                Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
               Object-Oriented Software Engineering: Using UML, Patterns, and Java
 Subareas of Requirements Engineering

                        Requirements Engineering



     Requirements Development             Requirements Management



Elicitation    Analysis        Specification           Validation
- sources      - req. types    - spec document         - reviews
- techniques   - modeling      - templates             - prototyping
               - negotiation   - quality               - acceptance test

                                                  Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                                                 Object-Oriented Software Engineering: Using UML, Patterns, and Java
            Purposes of
  a requirements spec documents
• A requirements spec document is used by many
  different stakeholder for different purposes:
  –   Customer - part of a formal contract
  –   Manager - basis for the project plan
  –   Developer - basis for the design and implementation
  –   Tester - document to test the system against
  –   Maintainer - starting point for understanding the
      system



                                     Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                                    Object-Oriented Software Engineering: Using UML, Patterns, and Java
What is a good requirement?




                 Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                Object-Oriented Software Engineering: Using UML, Patterns, and Java
        Necessary properties of
            requirements
• Unambiguous
   – the meaning should be clear
• Consistent
   – one requirement must not contradict another
• Complete
   – E.g.: “The process is terminated if the wrong PIN has been
     entered more than a certain number of times.” (What is that
     number?)
• Verifiable (possible to test)
   – a requirement that cannot be tested is not a requirement
   – E.g.: “The system should work in real-time mode.” (What is “real
     time” here?)

                                           Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                                          Object-Oriented Software Engineering: Using UML, Patterns, and Java
       A desirable property of
           requirements
• Free of implementation bias
  – What vs. how
  – Specification vs. solution
  – E.g.,
     • “The system shall accept a password when data is
       accessed.”
        This has a requirement to use password
     • “The system shall ensure that the data can be
       accessed only by authorized users.”
        This gives you an opportunity to search for alternatives


                                        Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                                       Object-Oriented Software Engineering: Using UML, Patterns, and Java
Content of a requirements specification


•   Purpose of the product
•   Stakeholders
•   Scope of the product
•   Requirements constraints
•   Relevant facts
•   Assumptions
•   Requirements

                                Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                               Object-Oriented Software Engineering: Using UML, Patterns, and Java
      The purpose of a product
• Concise statement of the business
  problem to be solved
• An example:
  – Your client has an electro-mechanical PBX running in his office building
    to provide telephone service within the building. The client is more or
    less happy with the system, except that when a line fails due to a fault in
    the PBX, it goes undetected for a very long time until some user detects
    the fault and reports it to the management for a fix. The management
    wants to replace the electro-mechanical PBX with a state-of-the-art
    telephone switching hardware box from ValuCom. However, ValuCom
    does not sell the necessary control software, and your client wants you
    to develop it.



                                                Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                                               Object-Oriented Software Engineering: Using UML, Patterns, and Java
                  Stakeholders

• People and organizations interested in the
  product
  – Customers, users, regulators, developers, architects,
    domain experts, analysts, marketing people, sales
    people, management, etc.
• Accurately determine and describe the
  stakeholders
• They are the main sources of requirements


                                    Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                                   Object-Oriented Software Engineering: Using UML, Patterns, and Java
            Scope of the product

• Determines the boundaries of the work to
  be studied
• Can use a context diagram to define the
  scope


  Your work      Indicate change in status
                                                           PBX
  (Control S/W                                             Hardware
  for PBX)       Produce control signal
                                                    Adjacent system
                                     Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                                    Object-Oriented Software Engineering: Using UML, Patterns, and Java
            Requirements constraints

• Global requirements having an effect on all or most of
  the requirements
• Solution Constraints
   – Describe any mandated design or solution constraint. (E.g.: The
     system must run on Unix.)
   – Identify partner applications. (E.g.: The product will interface with
     an existing module written in C.)
• Project Constraints
   – Time constraint: Must release the product at the 2004 Olympics.
   – Financial constraint: Indicates how elaborate the product can be.




                                              Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                                             Object-Oriented Software Engineering: Using UML, Patterns, and Java
                Relevant facts

• Conditions and factors that have an impact on
  the requirements

• Look for those when talking to the project
  stakeholders

• Example: The current PBX hardware supports
  60 phones, whereas a newer version next year
  will support 200 phones and the client wants to
  run the same software with the new PBX.
                                Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                               Object-Oriented Software Engineering: Using UML, Patterns, and Java
                 Assumptions

• Assumptions listed here are those being made
  by the project team

• If the assumptions are not satisfied, the success
  of the project may be endangered

• E.g., assumptions about performance or
  capacity of the hardware used, interfaces
  between the new and existing products

                                Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                               Object-Oriented Software Engineering: Using UML, Patterns, and Java
             Requirements
• Requirements are
  – the things that the product must do to achieve
    its purpose
       functional requirements


  – the qualities the product must have
      non-functional




                               Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                              Object-Oriented Software Engineering: Using UML, Patterns, and Java
   Functional requirements vs.
     technical requirements
• Think of the functional requirements as the
  business requirements
• You may introduce technical requirements
  during designing a solution for the
  functional requirements because of the
  technology used by your solution




                            Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                           Object-Oriented Software Engineering: Using UML, Patterns, and Java
     Functional vs. non-functional
            requirements

• Example: One of the functional requirements of
  your control software for the PBX is to
  automatically detect line faults. Detection of line
  faults is a functional requirement. Now let us say
  that a fault must be detected within 20 minutes.

• This is a performance requirement—a non-
  functional


                                 Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                                Object-Oriented Software Engineering: Using UML, Patterns, and Java
      Some types of non-functional
             requirements
• Look and feel
• Usability
• Performance
    – speed, memory and other resources, accuracy, volumes, range of
      values, reliability, …
• Operational
    – e.g., The product will be used by mobile technicians.
• Maintainability
    – e.g., Readily portable to Linux.
• Security
• Cultural and political
    – Acceptable solutions, unacceptable solutions, political correctness,
      spelling, and so on.

                                                 Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                                                Object-Oriented Software Engineering: Using UML, Patterns, and Java
    First Step in Establishing the Requirements:
                 System Identification


• The development of a system is not just done by taking a snapshot
  of a scene (domain)
• Two questions need to be answered:
   – How can we identify the purpose of a system?
   – Crucial is the definition of the system boundary: What is inside,
      what is outside the system?
• These two questions are answered in the requirements process
• The requirements process consists of two activities:
   – Requirements Elicitation:
        • Definition of the system in terms understood by the customer
          (“Problem Description”)
   – Requirements Analysis:
        • Technical specification of the system in terms understood by
          the developer (“Problem Specification”)

                                            Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                                           Object-Oriented Software Engineering: Using UML, Patterns, and Java
  Products of Requirements Process
                       (Activity Diagram)
   Problem
  Statement           Problem
                     Statement
                     Generation
Requirements
Elicitation
                     system
                 specification:
                      Model


Requirements
  Analysis

                     analysis
                    model: Model
                        Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                       Object-Oriented Software Engineering: Using UML, Patterns, and Java
           Requirements Elicitation

• Very challenging activity
• Requires collaboration of people with different
  backgrounds
   – Users with application domain knowledge
   – Developer with solution domain knowledge (design
     knowledge, implementation knowledge)
• Bridging the gap between user and developer:
   – Scenarios: Example of the use of the system in terms
     of a series of interactions with between the user and
     the system
   – Use cases: Abstraction that describes a class of
     scenarios
                                    Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                                   Object-Oriented Software Engineering: Using UML, Patterns, and Java
System Specification vs Analysis Model

• Both models focus on the requirements from the user’s
  view of the system

• System specification uses natural language (derived
  from the problem statement)

• The analysis model uses formal or semi-formal notation
  (for example, a graphical language like UML)

• The starting point is the problem statement


                                     Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                                    Object-Oriented Software Engineering: Using UML, Patterns, and Java
             Problem Statement
• The problem statement is developed by the client as a
  description of the problem addressed by the system
• Other words for problem statement:
   – Statement of Work
• A good problem statement describes
   – The current situation
   – The functionality the new system should support
   – The environment in which the system will be deployed
   – Deliverables expected by the client
   – Delivery dates
   – A set of acceptance criteria
                                    Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                                   Object-Oriented Software Engineering: Using UML, Patterns, and Java
         Ingredients of a Problem Statement
• Current situation: The Problem to be solved

• Scenaria: Description of one or more scenarios

• Requirements
   – Functional and Nonfunctional requirements
   – Constraints (“pseudo requirements”)

• Project Schedule
   – Major milestones that involve interaction with the client including
      deadline for delivery of the system

• Target environment
   – The environment in which the delivered system has to perform a
     specified set of system tests

• Client Acceptance Criteria
   – Criteria for the system tests                  Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                                                   Object-Oriented Software Engineering: Using UML, Patterns, and Java
                           Requirements Validation
• Requirements validation is a critical step in the development process
  and at delivery (client acceptance test).
• Requirements validation criteria:
   – Correctness:
       • The requirements represent the client’s view.
   – Completeness:
       • All possible scenarios, in which the system can be used,
          are described, including exceptional behavior by the user
          or the system
   – Consistency:
       • There are functional or nonfunctional requirements that
          contradict each other
   – Realism:
       • Requirements can be implemented and delivered
   – Traceability:
       • Each system function can be traced to a corresponding set
          of functional requirements            Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                                               Object-Oriented Software Engineering: Using UML, Patterns, and Java
              Requirements Validation
• Problem with requirements validation: Requirements change very
  fast during requirements elicitation.

• Tool support for managing requirements:
   – Store requirements in a shared repository
   – Provide multi-user access
   – Automatically create a system specification document from the
     repository
   – Allow change management
   – Provide traceability throughout the project lifecycle

•   RequisitPro from Rational
     – http://www.rational.com/products/reqpro/docs/datasheet.html



                                            Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                                           Object-Oriented Software Engineering: Using UML, Patterns, and Java
                      Scenarios
• “A narrative description of what people do and
  experience as they try to make use of computer systems
  and applications” [M. Carrol, Scenario-based Design,
  Wiley, 1995]

• A concrete, focused, informal description of a single
  feature of the system used by a single actor.
• Scenarios can have many different uses during the
  software lifecycle
    – Requirements Elicitation: As-is scenario, visionary
      scenario
    – Client Acceptance Test: Evaluation scenario
    – System Deployment: Training scenario.
                                     Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                                    Object-Oriented Software Engineering: Using UML, Patterns, and Java
         How do we find scenarios?

• Don’t expect the client to be verbal if the system does not
  exist (greenfield engineering)

• Don’t wait for information even if the system exists

• Engage in a dialectic approach (evolutionary, incremental
  engineering)
   – You help the client to formulate the requirements
   – The client helps you to understand the requirements
   – The requirements evolve while the scenarios are
     being developed
                                      Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                                     Object-Oriented Software Engineering: Using UML, Patterns, and Java
        Heuristics for finding Scenarios
• Ask yourself or the client the following questions:
   – What are the primary tasks that the system needs to perform?
   – What data will the actor create, store, change, remove or add in
     the system?
   – What external changes does the system need to know about?
   – What changes or events will the actor of the system need to be
     informed about?

• However, don’t rely on questionnaires alone.

• Insist on task observation if the system already exists (interface
  engineering or reengineering)
    – Ask to speak to the end user, not just to the software contractor
    – Expect resistance and try to overcome it

                                              Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                                             Object-Oriented Software Engineering: Using UML, Patterns, and Java
 Scenario Example: Warehouse on Fire
• Bob, driving down main street in his patrol car notices smoke coming
  out of a warehouse. His partner, Alice, reports the emergency from
  her car.

• Alice enters the address of the building, a brief description of its
  location (i.e., north west corner), and an emergency level. In addition
  to a fire unit, she requests several paramedic units on the scene
  given that area appear to be relatively busy. She confirms her input
  and waits for an acknowledgment.

• John, the Dispatcher, is alerted to the emergency by a beep of his
  workstation. He reviews the information submitted by Alice and
  acknowledges the report. He allocates a fire unit and two paramedic
  units to the Incident site and sends their estimated arrival time (ETA)
  to Alice.

• Alice received the acknowledgment and the ETA. is based on notes from Bernd Bruegge & Allen H. Dutoit
                                          Presentation material
                                                            Object-Oriented Software Engineering: Using UML, Patterns, and Java
Observations about Warehouse on Fire
              Scenario

• Concrete scenario
   – Describes a single instance of reporting a fire incident.
   – Does not describe all possible situations in which a
     fire can be reported.

• Participating actors
   – Bob, Alice and John




                                       Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit
                                      Object-Oriented Software Engineering: Using UML, Patterns, and Java

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:3
posted:10/18/2012
language:English
pages:36