Requirements Networking Group
Business Process Management: anatomy of an integrated solution
The term Business Process Management (BPM) is used in a number of varying contexts, from both a change management and a technology perspective. Many articles and analysis identify and list the requirements and the benefits of a BPM implementation. However, a crucial element is missing from these stories: how can we maximize the benefits of such initiative. We propose an approach that position BPM in its global business context.
Agile From The Trenches – A real world example
My last project was a 12 month green field development of a new broadband provisioning platform for a major ISP/Telco in the UK. I was the 2nd person to be recruited as Development Manager, the one other recruitee was a developer who was carrying out initial prototype work for the Enterprise Architecture team to prove that what was wanted by the business was actually achievable. The interview, in June 05, was pretty short, basically it went along the lines of “The business want X delivered by 1st Nov and they are not sure what X is, can you do it ?”
UML, RUP, and the Zachman Framework: Better together
A lot has been said recently about the advantages of using UML for modeling, RUP shines as a software development process, and Zachman passed the test of time as a framework for organizing and communicating architectural artifacts. In the swarm of overlapping methodologies these stand apart as three pillars of the modern architecture. This article embarks on the shared usages of these techniques by examining their meta-characteristics and discussing the applications that can be exploited by an organization.
Simulation and Modeling Driven Software Development
The development of the software for the Safeguard Anti-missile Missile System was a major challenge. There were no configuration control guidelines or standard software processes when software work began in 1965. The National Academy of Sciences thought that the software would not work. Only NASA’s software program faced the complexity and performance demands that Safeguard faced. Even though many techniques were borrowed from the Apollo project, a unique approach to software development evolved spontaneously. Many projects modeled and simulated system performance, but Safeguard was the first to use the models and simulations to drive its software development. After some early false starts, the entire software effort fell into lock step with the model and simulation program. This is the story of the effectiveness of this approach.
Use Case Concepts and their Effective Application Part III: Detailing Use Cases
The first two instalments in the series described the fundamental role that use cases play in describing a system’s functional requirements and the process for finding and briefly describing the actors and use cases for a system under study. (See: “Use Case Concepts and their Effective Application Part I: What are Use Cases?” and “Part II: Finding Actors and Use Cases”.) This instalment of the series explains the approach for detailing a system use case main flow of events and alternate flows. The common mistakes and pitfalls while authoring use cases are also discussed.
Optimal Trace: The Microsoft Word of Functional Requirements
While many requirements tools on the market focus on accessibility and convenience features they fail to fully address the main issue that made use case analysis so successful: functional requirements management. This article explains the benefits of scenario-centric framework implemented in Optimal Trace (also known as Steeltrace or Catalyze) for system development projects. It does not contain a comprehensive outline of all features of the tool, instead focusing on a distilled set that, in my opinion, makes the tool indispensable for both requirements beginners and experts.
Taking Software Requirements Creation from Folklore to Analysis
Large software systems are too often late, costly, and unreliable. Too often the requirements are not well understood or wrong. Understanding and bounding the requirements in a specification is an essential step to solving this problem. As early as 1970 Royce pointed at that unvalidated requirements leads to unmanageable projects. In particular, requirements complexity drives effort required to build software intensive systems, the time it takes to build them and their inherent reliability. Complexity management is critical and by enhancing existing simulation environments used by system engineers to formulate alternative system designs, software engineers can understand the sensitivity of requirements complexity to the likelihood of producing a workable system. Model–Driven Software Realization is a current practice for achieving this understanding. Combining functional and performance simulations with sizing and effort estimation efforts leads to a holistic understanding of feature, form, cost, schedule and trustworthiness.
Collecting Data Requirements
This article is the final part in a general series discussing the collection and documentation of data requirements for a system, especially when the requirements are being collected and documented using use case techniques.
- 5230 reads
