Java Reference
In-Depth Information
• Interoperability: there's no requirement to interoperate with any other
software but here's an idea for a future version: export/import into CSV
format for spreadsheets, and/or XML format for future expansion).
• Response time: “reasonable” interactive speed; subsecond response when
entering new accounts and values, so that the user can type quickly and
continuously; waiting, if it occurs, should only be at button presses, not
between data entries.
11.7.2
Stakeholder buy-in can be another important part of a software project. As we
discussed in Section 11.5, stakeholders are any of those people who are touched
in some way, direct or indirect, by this software project.
For this simple budgeting program, there will be few stakeholders—it will
largely be Ellen and her direct reports. The system will not likely be a large
drain on computing resources, so system admins don't need to be brought in
at this point. If and when the project expands to include other users across the
network and across the enterprise, then the system administrators should
definitely be included. There will be few reports from this first cut of the
project, and what few there are will only be read by Ellen and her direct reports,
so again, there are few others that need to be consulted as stakeholders.
The idea at this stage is to listen to other points of view—those of your
stakeholders—to get a different perspective before charging headlong down
one avenue of development.
It's not that you will be able to satisfy all points of view—it can be a wor-
thy goal, but it is often unattainable. Rather, you need to hear from all those
involved since your software will affect all those people, and understanding
something about how it will fit into their roles and daily tasks will help you
make better tradeoffs and design better software. It will likely uncover previous-
ly unseen requirements. It also has the political benefit of those people knowing
that you cared enough to listen to them before sending them a finished solu-
tion. It increases the likelihood that your software will be seen as a help, not
hinderance.
4
Stakeholder Buy-In
4. As engineering types it is difficult for us to understand and appreciate the importance of
this, but in many ways these personal, political, and psychological factors are much more im-
portant to the success of a project than are technical choices. It has taken us years to appreciate
