Documenting architectures Architectures are documented by views, and so that is how we proceed too. The goal of a view is to describe the system from the viewpoint of its stakeholders. Several architectural view models exist and probably the most famous one is the 4+1 model of Kruchten (see here). For the energy harvester we […]
Review: Requirements Management with Enterprise Architect 9.3
Introduction In order to manage the requirements of our energy harvester project we use Enterprise Architect (EA) from Sparx Systems, an Australian company. Enterprise Architect is a (UML-based) modeling and design tool which integrates…well…everything: requirement management, project management, database engineering, business modeling, code engineering, test management… Really, the list of features (click here) is endless. […]
From stakeholder to system requirements
System requirements and their organization Given our stakeholder requirements and some basic domain knowledge, we can now initiate the system requirements. Instead of extending the rather informal and unstructured stakeholder requirements, we prefer to start with a brand new set of requirements which is organized in a hierarchical structure (divide and conquer!) in which: the […]
Stakeholder requirements
Introduction End-users, developers, testers, production, project managers, business, sales… they all have their interest in the system and are called stakeholders. At first, it is the task of the system architect to collect those interests (or concerns as recent literature suggests [ref]) and to resolve (potential) conflicts. Communication is key since stakeholders do not necessarily […]
Recent Comments