1 / 10

Feasibility and Desirability analysis

Feasibility and Desirability analysis. Colin Potts Georgia Tech. Requirements’ priorities. Not all requirements are equal Even contractual requirements are often renegotiated Product requirements are often assigned priorities low priority reqts. may be jettisoned to reduce time-to-market

osgood
Download Presentation

Feasibility and Desirability analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Feasibility and Desirability analysis Colin Potts Georgia Tech

  2. Requirements’ priorities • Not all requirements are equal • Even contractual requirements are often renegotiated • Product requirements are often assigned priorities • low priority reqts. may be jettisoned to reduce time-to-market • Priorities may be {1, 3, 9} or {possible, deferred, rejected}, etc. • Priorities depend on stakeholders • Different stake value reqts. differently

  3. Overview: QFD and prototyping • Quality Function Deployment (QFD) • Highly structured approach for tabulating reqts./design interactions & evaluating alternatives • Prototyping • Early development of executable models for customer to evaluate system concept

  4. Quality function deployment (QFD) • Japanese technique for design & manufacturing • Principal tool is the “house” of quality • Complex matrix showing dependencies & trade-offs • Simultaneous analysis of customer needs, engineering design & market data lends QFD to multi-function teams

  5. Building a “house” Design attributes Customer needs (named reqts.) Customer evaluations Eng. measures

  6. Prototypes • Prototype construction is standard practice in engineering • cf. wind tunnels, computational models, artist's impression, etc • Design involves much exploration • Requirements can be validated by prototyping • To explore whether requirements really reflect users' needs • Prototypes reduce risk • Prototypes are used during feasibility studies • Prototypes can be constructed from reusable parts • Typically use 4GL, interface builders, application libraries, etc.

  7. Effectiveness of prototyping • Empirical studies • Boehm et al (Proc. ICSE, 1986) • Alavi et al (CACM, 1986) • Most evidence is anecdotal • Experiment: incremental development (P) vs. specification-based design (S) • Student team projects to build estimation package • No difference in performance • P led to 40% smaller code • P required 55% effort of S • P led to less functionality, poorer reliability and poorer maintainability, but was easier to use and learn

  8. Effectiveness of prototypes (cont.) • Analyst and manager survey • $5K to $630K projects • Perceived benefits of prototyping • Better feedback about requirements • Prototype provided common medium of communication (users and experience develop better working relationship) • Users become more enthusiastic • Perceived limitations of prototyping • Easy to oversell • Difficult to plan and control prototype development • Temptation not to throw away

  9. Scenarios and storyboards

  10. Feasibility & desirability: how to find out more • QFD • Articles in HBR etc. • Prototyping • Many articles in IEEE Software and elsewhere • Book by Vonk

More Related