Adopt a System Approach to Software Requirements |
|
|
|
| Written by Graham Stoney |
|
Software doesn't exist in isolation; it is always part of a larger system. You should adopt a Systems Engineering approach to requirements management, even if you system is software-only. If you're developing a software-only product, the user is probably supplying the hardware on which the software will run, but it's still part of the system you're building. For example, you should specify the minimum configuration of hardware that your software will target, and the operating system that will be required. These result from design choices made based on your system requirements analysis of the system stakeholder requirements. The reason that there is no software stakeholder requirements activity specified in ISO 12207 is that stakeholder requirements affect the whole system, and these are captured at the system level as described in ISO 15288. A simplification you can make in software-only developments is to collapse the system requirements analysis and the software requirements analysis activities into one; but you should still approach your software engineering activity keeping all my system engineering tips in mind. If the system you're developing has hardware components as well, then your software development should function as one of the system development activities, alongside the hardware engineering effort. Even if the hardware components are off-the-shelf items, they still have requirements and system-level decisions need to be made about which stakeholder requirements will be met by the hardware, which will be met by the software, and which will be met by a combination of the two. Adopting a system perspective to all this allows the software engineering to work cleanly alongside the other discipilines in the project. Avoid treating software radically differently. |












