Corporate Education Group

The Quest for Good Requirements

CEG offers Corporate Training and Consulting, as well as traditional and virtual instructor-led courses in management and leadership, project management, business analysis, business process management, agile/scrum, and lean six sigma.

Issue link: https://info.corpedgroup.com/i/1209615

Contents of this Issue

Navigation

Page 2 of 8

The Quest for Good Requirements | 3 300 Brickstone Square • Suite 201 • Andover, MA 01810 USA • 1.800.288.7246 • +1.978.649.8200 • info@corpedgroup.com Stakeholders The stakeholders are the main source of requirements. They have specific needs that the analyst must identify. This is easier said than done: often, stakeholders are not quite sure what they need and they often don't know how to express what they need. It is the analyst's job to help uncover the requirements of the stakeholders. A stakeholder is anyone who has an interest in the successful outcome of the project, including project sponsors, users, business executives, managers, developers, clients, customers, vendors, and government or regulatory agencies. Eliciting requirements is surprisingly hard work. Stakeholders often do not know exactly what they need and eliciting the requirements can be quite challenging. As Fred Brooks has stated so poignantly in his seminal essay "No Silver Bullet: Essence and Accidents of Software Engineering"¹: "The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirement, including all the interfaces to people, machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later." He goes on to say that in a systems development project there are two kinds of complexities that must be managed: accidental and essential (or inherent). Much of software engineering is focused on reducing accidental complexity, which is the complexity that we add to a project by way of the tools and programming languages that we use. For example, writing code in C is much harder than Java, and writing code in Java is much harder than doing a "mashup"² with web components. While it is good to focus on reducing accidental complexity, much of the complexity of a project is rooted in essential (or inherent) complexity. Essential complexity is the difficulty of the problem itself: launching a rocket into orbit is hard no matter what programming language you use. The techniques studied in this book are about managing essential complexity.

Articles in this issue

Links on this page

view archives of Corporate Education Group - The Quest for Good Requirements