Non Functional Requirements for Library Management System by lwt20017

VIEWS: 2,417 PAGES: 25

More Info
									Software Requirements and
the Requirements Engineering

       Chapters 5 and 6
   Software Engineering. Ian Sommerville. 6th edition.
   Code Complete. Steve McConnell. (CC)
   The art of requirements triage. Alan M. Davis.
    Computer. IEEE. March 2003.
   Testing whether requirements are right. Robin F.
    Goldsmith, JD. Go Pro Management Inc. NYC Spin
    Meeting. December 2004. (RG)
   Software Requirements. Karl E. Wieger. Windows
   Dr. Gotel’s research web page
   Dr. Barrett’s slides, NYU
         What is a requirement?
   It is about WHAT not HOW
   Nothing can be said obvious
   Requirements are the descriptions of the services
    provided by a system and its operational constraints
   It may range from a high level abstract statement to
    a detailed mathematical specification
   It may be as complex as a 500 pages of description
   It may serve as the basis for a bid for a contract or
    the basis for the contract itself
What is requirements
   It is the process of discovering,
    analyzing, documenting and validating
    the requirements of the system
   Each software development process
    goes through the phase of requirements
Why requirements?
   What are the advantages of a complete set of
    documented requirements?
       Ensures the user (not the developer) drives
        system functionalities
       Helps avoiding confusion and arguments
       Helps minimizing the changes
   Changes in requirements are expensive.
    Changing the requirements costs:
       3 x as much during the design phase
       5-10 x as much during implementation
       10-100 x as much after release [Code Complete,
Why requirements?
   2/3 of finished system errors are
    requirements and design errors [RG]
   A careful requirements process doesn’t mean
    there will be no changes later
       Average project experiences about 25% changes
        in the requirements
       This accounts for 70-80% if the rework of the
        project [Code Complete, p40]
       Important to plan for requirements changes
   The case of critical applications
Different levels of abstraction
   User requirements (abstract +)
       Usually the first attempt for the description of the
       Services and constraints of the system
       In natural language or diagrams
       Readable by everybody
       Serve business objectives
   System requirements (abstract -)
       Services and constraints of the system in detail
       Useful for the design and development
       Precise and cover all cases
       Structured presentation
   User requirement: The library system should
    provide a way to allow a patron to borrow a book
    from the library.
   System requirement: The library system should
    provide a withdraw interaction that allows a
    patron to withdraw a book given the isbn and
    copy number of the book to be withdrawn. The
    interaction fails if: the book is already withdrawn,
    the book is not in the library's collection, the
    patron has already withdrawn 5 books, the patron
    owes more than $5, the book is on hold by
    someone else. Otherwise…(To be completed)
    Types of requirements
   Functional requirements
        Services the system should provide
        What the system should do or not in reaction to particular
   Non-functional requirements
        Constraints on the services or functions offered by the system
        Examples: Timing constraints, constraints on the development
         process (CASE, language, development method…), standards etc
   Domain requirements
        From the application domain of the system
        May be functional or non-functional
        Examples: Medicine, library, physics, chemistry
   Note: You can have user/system functional/non-functional
User requirements
   First attempt to describe functional and non-
    functional requirements
       Understandable by the user
   Problems:
       Lack of clarity - ambiguous language
       Requirements confusion - functional, non-functional
        requirements, design information are not distinguished
       Requirements amalgamation – several requirements are
        defined as a single one
       Incompleteness – requirements may be missing
       Inconsistency – requirements may contradict themselves
             User requirements
   Guideline to minimize the issues:
       Separate requirements – separate the requirements,
        separate functional and non-functional requirements,
        requirements must be clearly identified (e.g. by a number)
       Include a rationale for each requirement – helps clarify
        reasoning behind the requirements and may be useful for
        evaluating potential changes in the requirements
       Invent or use a standard form/template
       Distinguish requirements priorities
            Example: MoSCoW (Must, Shall, Could, Want/Will (no TBD))
       Avoid technical jargon
       Testable (write test cases)
       Deliverables
System requirements
   Elaborate the user requirements to get a
    precise, detailed and complete version of
   Used by designers and developers
   An important aspect is how to present/write
    system requirements
       Natural language is often used!
   The difference between user and system
    requirements must not be thought as a detail
System requirements
   Example: If sales for current month are below
    target sales, then report is to be printed
    unless difference between target sales and
    actual sales is less than half of difference
    between target sales and actual sales in
    previous month, or if difference between
    target sales and actual sales for the current
    month is less than 5%.
   Problems:
       Difficult to read
       Ambiguity: sales and actual sales, 5% of what?
       Incomplete: what if sales are above target sales?
Writing system requirements
   Natural language (informal requirements)
       Reviled by academics
       But widely practiced: everybody can read them, finding a
        better notation is hard
   Structured natural language
       Forms/templates are used to bring some rigor to natural
        language presentations
   Graphical notations
       Using boxes, arrows… but they mean different things to
        different people
   Formal specification
       Based on logic, state machines…
       Hard to understand for many people
An analogy
   Archimedes (ca. 250 bc)
       Any sphere is equal to 4 times the cone which has
        its base equal to the greatest circle in the sphere
        and its height equal to the radius of the sphere.
   Today
       V = 4/3 pi r   3

   How is this bit of history relevant for software
       Formal is better only if everybody understands it
       It may take a long time to find a good notation
       Software requirements is an area of research
Non-functional requirements
   They can be further categorized into:
        Product requirements
             Product behavior
             Ex: Timing, performance, memory, reliability, portability,
        Organizational requirements
             Policies and procedures in the customer’s and developer’s
             Example: Process requirements, implementation requirements,
              delivery requirements
        External requirements
           Factors externals to the system and the development process
           Example: Interoperability, legislation, ethics

   Non-functional requirements may be more critical than functional
    requirements. (The system may be useless…)
     Non-functional requirements
                                                          requir ements

                                Product                  Or ganizational                   External
                             requir ements                requir ements                  requirements

          Ef ficiency         Reliability        Portability        Interoperability        Ethical
         requir ements       requir ements     requirements          requirements        requirements

  Usability                               Delivery       Implementation         Standards         Legislative
requirements                            requirements      requir ements       requirements       requirements

Performance           Space                                                      Privacy            Safety
requirements       requir ements                                              requirements       requirements
         Non-functional requirements
   It is important to be able to test/verify/check
    non-functional requirements
       Prope rty        Mea sure
       Sp eed           Processed transaction s/seco nd
                        User/Ev en t resp onse time
                        Screen refresh t ime
       Size             K Byt es
                        Number of RAM ch ip s
       Ease o f use     Training t ime
                        Number of help frames
       Reliability      Mean time t o failure
                        Probabilit y of unavailability
                        Rate o f failure o ccurren ce
                        Availabilit y
       Ro bustn ess     Time to restart after failure
                        Percent age of events causin g failure
                        Probabilit y of dat a co rrup tion on failure
       Po rt abilit y   Percent age of t arget dependent statemen ts
                        Number of t arget sy st ems
Requirements documents
   The library system requirements document
    (Available in the Blackboard)
       Very readable
       Some ambiguities
   Examples of templates (Available in the
       Microsoft template. Karl E. Wiegers. Software
        Requirements. Windows Press.
       Volere template
Requirement engineering
   5 important activities:
       Feasibility study
       Requirements elicitation and analysis
       Requirements documentation
       Requirements validation
       Requirements management
  Requirement engineering
Feasibility   Requirements
  study       elicitation and
                                Requir ements
Feasibility                                       Requirements
  report                                           validation
                                User and system

Feasibility study
   It is done at first to decide whether or
    not the project is worthwhile
   Look at different perspectives:
       Market analysis, financial, schedule,
        technical, resource, legal…
   Should make you aware of the risks
Feasibility study
   Doing the study
       Consult information sources: managers,
        software engineers, end users…
       Based on information collection
        (interviews, surveys, questionnaires…)
   Should be short (2-3 weeks)
   2 examples of feasibility studies are
    posted in the Blackboard
    Feasibility study
   What if the system wasn’t implemented?
   What are current process problems?
   Do technical resources exist?
   What is the risk associated with the technology?
   Is new technology needed? What skills?
   How will the proposed project help?
   How does the proposed project contribute to the
    overall objectives of the organization?
   Have the benefits identified with the system
    being identified clearly?
Feasibility study
   What will be the integration problems?
   What facilities must be supported by the
   What is the risk associated with cost and
   What are the potential
   Are there legal issues?
   Are there issues linked with the fact that this
    is an offshore project?
   …

To top