Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

Requirements

VIEWS: 3 PAGES: 46

									Requirements

    CS121
  Spring 2010
            Administrivia
• new student: Guillermo
• artist: Jackie Wijaya
     Requirements




“What does the customer actually want?”
         Types of Requirements:
                FURPS+
• Functional: features, capabilities
• Usability: human factors, aesthetics, consistency,
  documentation

• Reliability: frequency of failure, recoverability, predictability
• Performance: response times, throughput, accuracy,
  availability, resource usage

• Supportability: adaptability, maintainability, configurability
• +: others
      Why are requirements so
            important?
• We need to know what we are supposed
  to build before we can build it.   duh

• Failures at this stage are costly.
                           when problem is introduced


when problem is requirements    design              construction
found
requirements    1x

design          3x              1x

construction    5-10x           10x                 1x

system test     10x             15x                 10x

post ship       10-100x         25-100x             10-25x
      Why are requirements so
            important?
• We need to know what we are supposed
  to build before we can build it.   duh

• Failures at this stage are costly.
• Failures at this stage are common.
Most errors found by users in software are
  the result of
A. coding errors
B. errors in requirements
C. system integration errors
D. errors in the design of the solution



Answer: B
                            “Software’s Chronic Crisis”
Why are requirements so difficult to
            specify?
• Customer’s can’t tell you what they want
Why are requirements so difficult to
            specify?
• Customer’s can’t tell you what they want
  – they don’t know
  – they don’t clearly articulate their needs
Why are requirements so difficult to
            specify?
• Customer’s can’t tell you what they need
  – they don’t know
  – they don’t clearly articulate their needs
• Customer’s have conflicting needs
      You must control at least one parameter!

               Customer: I want to pay $500 for its development
                               Cost




          Quality                                 Time
Customer: I want the best RPG ever                Developer: It will be finished
                                                  when hell freezes over.
Why are requirements so difficult to
            specify?
• Customer’s can’t tell you what they need
  – they don’t know
  – they don’t clearly articulate their needs
• Customer’s have conflicting needs
• Customer’s needs change
% increase in requirements
                                            Growth in requirements
                                                   Creeping Req's as % of Orig


                                                                                 60
                             during project life




                                                                                 50
                                                                                 40
                                                                                 30
                                                                                 20
                                                                                 10
                                                                                 0
                                                                                         10          100        1000        10000       100000
                                                                                              Project Size in Function Points

                                                                                  Source: Applied Software Measurement, Capers Jones, 1997. Based on 6,700 systems.
Why are requirements so difficult to
            specify?
• Customer’s can’t tell you what they need
  – they don’t know
  – they don’t clearly articulate their needs
• Customer’s have conflicting needs
• Customer’s needs change
• Technology changes
Developing requirements: Best Practices
    Developing Requirements
• Inception:
  – define initial concept
  – identify stakeholders
 Developing requirements

Management



  Marketing


               Software Engineer
     …




    Users



stakeholders
Developing requirements for
          games
Management



 Marketing


                Game Designer
   …




  Users



               Software engineers
    Developing Requirements
• Inception:
  – define initial concept
  – identify stakeholders
  – gather background information: competitive
    analysis, technology review, etc.
  – identify “perceived requirements“
    Developing Requirements
• Inception
• Elicitation: Ask the customer what they
  want
      Requirements Elicitation
                I want you
                to build a
                  game ...




customer/stakeholder         software engineer
      Requirements Elicitation
                I want an RPG
                 better than
                anything seen
                   before!




customer/stakeholder            software engineer
      Requirements Elicitation
               Ok ... off you go!

                Call me when its
                      done.




customer/stakeholder                software engineer
            Requirements
• Inception
• Elicitation: What do customer say they
  want?
• Analysis: What does the customer really
  want?
        Requirements Analysis
                        OK here is my
                         idea for the
                       game. What do
                          you think?




customer/stakeholder                    software engineer
       Requirements Analysis
                Great! Can I have
                 it next week?




customer/stakeholder                software engineer
            Requirements
• Inception
• Elicitation: What does the customer say
  they want?



• Analysis: What does the customer really
  want? What can you realistically provide?
Feasibility: Can we meet the constraints?



                 Cost




   Quality                   Time
               Feasibility

• Understand the proposed system
• Understand the capabilities of your team
  and tools
• Explore gaps (or risks)
            Requirements
• Inception
• Elicitation: What does the customer say
  they want?



• Analysis: What does the customer really
  want? What can you realistically provide?

              Software Requirements Specification (SRS)
                 Waterfall Model
                    with feedback


Requirements            SRS



               Design



                         Implementation



                                          Test
              Agile requirements
Project inception:
• Identify high level scope
• Key requirements
• Initial “goal stack”

                                           highest priority, best modeled
                                           goals


                              Well modeled means we understand what to do
                              and how long it will take.




                                          lowest priority, least modeled goals
                      Agile requirements
At the start of each iteration:
•    Incorporate new goals (often produced by last iteration)
•    Remove items no longer needed
•    Reprioritize
•    Clarify requirements for goals at top of stack
•    Plan iteration

                                                                highest priority, best modeled
                                                                goal


                                                     Who prioritizes?
                                                             Customer driven
                                                             Risk driven




                                                            lowest priority, least modeled goal
         Requirement Quality
•   Specify what not how
•   Unambiguous
•   Testable
•   Feasible
•   Consistent
•   Prioritized
•   Traceable
•   Agreed upon by customer
         Next time: elicitation
           demonstration
• Meet the customer
• 1 team will do and in-class elicitations
• other teams will do their elicitation wed.
  after class (or if need be thursday
  morning)
          Prior to Elicitation
• Prepare short (2-4 slide) concept
  presentation
• List of “perceived” requirements and
  questions to clarify them
• Open ended questions to better
  understand needs
            Elicitation format
• Introduce yourselves and provide agenda
• Give your (2-4 slide) concept presentation
• Start with open-ended information gathering


                This is where you’ll discover
               issues you haven’t thought of
                        on your own.
              Elicitation format
•   Introduce yourselves and provide agenda
•   Give your (2-4 slide) concept presentation
•   Start with open-ended information gathering
•   Follow up on new issues raised
•   Discuss “perceived” requirements



                        Based on your background research
                        you should have some reqs in mind
                             before the meeting starts.
           Elicitation format
• Introduce yourselves and provide agenda
• Give your (2-4 slide) concept presentation
• Start with open-ended information gathering
• Follow up on new issues raised
• Discuss “perceived” requirements
• Discuss priorities
• Present a summary of key points and give him
  an opportunity to confirm/correct
• Thank him
            Elicitation roles
• Moderator: Leads the meeting, discussion
• Scribe: Takes notes
• Others
  – Distill discussion for final summary
  – Keep track of points that need clarification
  – Keep track of pre-determined requirements
    that need validation
  – Watch clock, agenda
            Elicitation Report
•   When, where, and who
•   Summarize discussion
•   New requirements
•   Validation of prior requirements
•   Priority of requirements
•   Any other interesting information
              Sample questions
•   Why are requirements so important?
•   Why are they so difficult to specify?
•   What are the various types of requirements?
•   What are the first steps of requirements gathering?
•   What is a customer elicitation?
•   What is involved in requirements analysis?
•   What is an SRS?
•   What constitutes quality in requirements?
•   How are requirements managed in agile processes?
     Assignment for next time
• Prep for elicitation
  – concept presentation
  – open ended questions
  – perceived reqs and questions to clarify
  – roles assigned to team members
     Scheduling of elicitations
• In-class
• After-class

								
To top