Article Name:

The Beginning - Requirements Frederick P Blume Jr

Why do we build new software? Is there really a need, a need for CUSTOM software? Short answer, yes. Each business has some new "twist" on how it does its business, how the workflow goes for each employee. Every business is trying to fill a niche, to be unique, to provide value - that no one else is doing exactly the way envisioned by the business owner, the visionary, the primary stakeholder. So, there will always be a need for custom software - or software that can be customized enough - to fulfill the requirements of the stakeholders, support the workflow of each user. That's what custom software is about. That being the case, there are some industry-standard practices for capturing those requirements - for each user. Requirements AND what they need to do their jobs - in the specific order and flow of how they do them. In this case, it is the Use Case that serves best. Take this website for example. What are the needs of people who use this site - in search of a software engineer who can get their requirements turned into working software? How would this site provide that kind of information in a form that is understandable to all stakeholders? A use case should show that. An example is in order here: "~/Content/models/BSEUseCase.pdf"

Getting Started Part 2 Use Cases FPB

Without Use Cases and/or User Stories, how do your people communicate requirements? The "Details" tell it all.

Activity and Object Decomposition FPB

Use cases are useful in capturing the expected and unexpected behavior of the users and the system. However, at some point, the system objects discovered in the process of building the use cases - must begin to take a new form, one that begins to take the activities and behaviors in the direction of software architecture. What objects are responsible for what activities/behaviors? Have we captured all the use cases and alternate flows that might result from unexpected conditions? Activity Diagrams are useful for discovering behavior not previously thought through by the stake holders who are responsible for providing the requirements of their new system. It allows the business analyst and the systems analyst to put the use cases to the test - and to begin to formalize the architecture, the planned structure of the system. In this instance, the "View Articles" Use Case is decomposed in terms of its activities.

Objects - Real world FPB

Why is Object-Orientation the best way to discover the structure of your system? Some (actually many) are now saying it's not. Among those are the ones who are now building Service-Oriented Architectures. Others claim OO doesn't work. I believe the truth is in there somewhere...