[175] in Project_DB
Requirements vs. Expectations
daemon@ATHENA.MIT.EDU (Tim McGovern)
Tue Jul 29 12:19:21 1997
Date: Tue, 29 Jul 1997 12:13:04 -0400
To: project-db@MIT.EDU
From: Tim McGovern <tjm@MIT.EDU>
As we begin our requirements gathering, we would be wise to keep the
following distinctions in mind.
Tim
>Mime-Version: 1.0
>Date: Tue, 29 Jul 1997 10:36:31 -0400
>To: pd-team@MIT.EDU
>From: Greg Anderson <ganderso@MIT.EDU>
>Subject: The Cutter Edge: July 29, 1997
>
>Happy mid-summer everyone!
>
> I thought you might find this useful since so much of our work
>deals with both expectations and requirements.
>
>Greg
>
>>>To: cutter_edge@world.std.com
>>>Subject: The Cutter Edge: July 29, 1997
>>>From: The Cutter Edge <cutter_edge@world.std.com>
>>>Sender: cutter_edge-approval@world.std.com
>>>Precedence: list
>>>Reply-To: cutter_edge@world.std.com
>>>
>>>Welcome to The Cutter Edge, the weekly e-mail service for IT
>>>professionals, provided free by Cutter Information Corp.
>>>+++++++++++++++++++++++++++++++++++
>>>
>>>This week's Cutter Edge has been written by Rob Thomsett, a member of
>>>AMERICAN PROGRAMMER's Editorial Advisory Board and a frequent
>>>contributor.
>>>
>>>REQUIREMENTS ARE NOT THE SAME AS
>>>EXPECTATIONS. SO ... WHAT ARE EXPECTATIONS?
>>>
>>>The word "expectations" has probably been more abused and misunderstood
>>>than any other word in the computing culture. To many project managers
>>>and systems analysts, expectations are simply those elements of the
>>>requirements that the clients did not specify. To others, expectations
>>>are the difference between what the clients want and what they really
>>>need. For the battle-hardened project manager, expectations are a
>>>wish list that begins a series of hard negotiations to determine
>>>minimum requirements. Finally, expectations are a hopelessly vague
>>>set of fuzzy requirements that defy documentation.
>>>
>>>These "definitions" notwithstanding, it is our experience that
>>>expectations are a related set of specific requirements that can be
>>>analyzed and modeled. It's just that data flow, data model, and other
>>>system-oriented techniques do not capture all the requirements
>>>for a business system.
>>>
>>>When business experts talk about their expectations, they are talking
>>>about four related sets of requirements:
>>>
>>>FUNCTIONAL REQUIREMENTS
>>>
>>>Functional requirements deal with the business processes, data, and
>>>documents that are the basis of the information system. Techniques such
>>>as use cases, OOA and OOD diagrams, data flows, and data models
>>>were designed for and, when used properly, are capable of documenting
>>>these. In addition, visual development environments such as Visual
>>>Basic, PowerBuilder, Delphi, and so on can also be used to capture
>>>these requirements through the use of prototypes and early
>>>working versions.
>>>
>>>Functional requirements are what the clients want.
>>>
>>>QUALITY REQUIREMENTS
>>>
>>>Quality requirements are often confused with functional requirements but
>>>cannot be modeled using standard systems modeling techniques. As I
>>>discussed in *Third Wave Project Management* (Prentice Hall, 1989),
>>>quality requirements include attributes such as conformity
>>>(functionality), efficiency, reliability, maintainability,
>>>flexibility, portability, auditability, security, usability, and
>>>reusability. By using techniques such as Software Quality
>>>Agreements, the team can model which quality attributes the clients
>>>require and the level to which related quality criteria must
>>>be delivered. (For example, conformity has the related criteria
>>>of completeness, correctness, and traceability.)
>>>
>>>Quality requirements describe how well the functional requirements must
>>>be developed.
>>>
>>>CONSTRAINTS
>>>
>>>An additional set of requirements is the constraints operating upon the
>>>project. Conformance to deadlines, costs, technology platform, staffing,
>>>organizational policy, and legal impact are typical constraints.
>>>Constraints have a major impact on a project's ability to
>>>deliver functional and quality requirements. Constraints are relatively
>>>easy to model and should be documented separately from functional
>>>and quality requirements.
>>>
>>>Constraints define when and how the product must be developed.
>>>
>>>ADDED VALUE REQUIREMENTS
>>>
>>>This set of requirements is probably the most important component of
>>>expectations. Traditional approaches to project management and systems
>>>analysis used extremely crude models of cost-benefit analysis. The
>>>common use of intangible benefits such as improved customer satisfaction
>>>or management decision-making to justify projects and the lack
>>>of formal approaches to benefits realization have perpetuated loose
>>>and fuzzy concepts of added value. As I described in *Third Wave
>>>Project Management*, techniques such as the added value chain, the
>>>identification of primary and secondary benefits, and stakeholder
>>>buy-in can effectively model the business clients' expectations of
>>>financial benefits from the project. In addition, these techniques
>>>also clarify the real business objectives.
>>>
>>>Added value is why the clients are really undertaking the project.
>>>
>>>You must meet your clients' expectations rather than just their
>>>requirements. Doing this requires you to get to know your clients as
>>>people first and as clients second. Understand your clients, and
>>>you'll understand their expectations.
>>>
>>>Rob Thomsett
>>>The Thomsett Company
>>>e-mail: 100250.1157@compuserve.com
>>>http://www.ozemail.com.au/~thomsett
>>>AMERICAN PROGRAMMER Editorial Board: http://www.cutter.com/amprog/
>>>
>>>+++++++++++++++++++++++++++++++++++
>>>
>>>If you'd like to comment on today's Cutter Edge, send e-mail to
>>>theedge@cutter.com, or send a letter by fax to +1 617 648 8707 or by
>>>mail to The Cutter Edge, 37 Broadway, Arlington, MA 02174-5552 USA
>>>+++++++++++++++++++++++++++++++++++
>>>
>>>You and your colleagues can hear more on Project Management from Rob
>>>Thomsett. Audio tapes of his 90-minute American Programmer Summit '97
>>>keynote address are now available. Visit the Cutter Web site,
>>>http://www.cutter.com/itgroup/ and click on the link for the Report
>>>Library, or call Kara Lovering at 617-648-8702
>>>(or 800-964-8702, toll-free in North America).
>>>+++++++++++++++++++++++++++++++++++
>>>
>>>To unsubscribe to The Cutter Edge, send e-mail to
>>>majordomo@world.std.com and include the message "unsubscribe
>>>cutter_edge" in the body of the message.
>>>
>>
>
