What I want to discuss in this article is my own mytholody for Software Development. I am going to do a few segments on this topic, but starting with this post, I want to specifically discuss how I believe the Requirements Gathering part of the SDLC (Software Development Lifecycle) process *should* be handled.
With this in mind, this article will go over the following key points:
- Two Styles of SDLC
- Non-Interactive Process
- Interactive Process
- My Preferred Method, which I dub “The RogueLogic Method”
Two Styles of SDLC
- There are two “styles” of the Software Development Lifecycle (SDLC) that applies to Enterprise Software Development.
- Either style can follow traditional Waterfall models or more modern Agile, Scrum, and other Iterative, quick time-to-market models.
Style One: Non-Interactive
- The First style, is what I refer to as the “Non-Interactive Process”, where representatives, usually labeled as Business Analysts acts as a liaison between the actual Users (aka the Business Community) and the Development Team.
- Requirements are defined by the business either explicitly through written examples or implicitly through walk-throughs of their day to day activities and it is the BA’s job to record these requirements into a format that is easily digested by the Development Team, which may or may not be familiar with the business domain themselves.
- Priorities are worked out with the business for each requirement by the BA Team.
- The Development Team then reviews the Requirements one by one with the Business Analyst team and works to create technology solutions for each requirement line by line, and each requirement is delivery according to the priorities given by the Business.
- The issue with this approach is that without input from the Development Team on the requirements, systems are usually built in a fashion that is neither stable nor scalable, because it takes a lot of “hacking” just to make a requirement appear to be working as requested by the users.
- Based on my professional experience, most systems build using this Style require either huge overhauls or complete re-engineering within a few short years.
Here’s a diagram of the Non-Interactive Requirements Process:
Style Two: Interactive
- The second style is what I refer to as the “Interactive Process”.
- The primary goal of the Interactive Process is to create a Partnership, where all parties involved, from the Business Users, to the Business Analyst Team, to the Development Team have an “Ownership” stake in the system or application which they are building and investing in.
- The start of the process is exactly the same as Style One.
- The process diverts from the first style at the point where the Business Analyst team engages the Development Team.
- At this point, the real value of the Development Team’s IT knowledge and experience and perhaps even prior experience in the Business Domain, really starts to become useful to the process.
- Requirements are treated as “requested” functions of features, and each function has an associated importance and priority by the business.
Additional Considerations for the Interactive Process
- It is the job of the Development Team to review each Requirement and based on various inputs, the requirements may be reworked, reordered, or deferred to future releases.
- These inputs are:
- Human Resources
- Technology Resources (Servers, Disk Space, Network, etc)
- Time to Market Issues
- Current Technology Limitations or Capabilities
- Architectural Standards
- IT Cost Issues
- Finally, each feature MUST be built in such a way that ensure the broader system or application is Stable, Scalable, Flexible, Extendible, and easily Maintainable.
Deferring Requirements, Phasing and De-scoping
- To be clear, not a single requirement is de-scoped, however based on the technology inputs, the Development team will strongly suggest and even influence the decisions to “defer” certain functions for future releases.
- By deferring a function or feature, this buys time for the development team to resolve technological hurtles that may have caused the requirement to be deferred in the first place.
- Deferring a feature implies that we will have multiple phases or releases in the project. I usually think of these as “Versions”. And like all real-world software, it is natural for systems and applications to go through many releases over the years it is in Production. So this approach seems most natural.
Here’s a diagram of the Interactive Requirements Process:
The RogueLogic Method
- The RogueLogic Method is to use the Interactive Process to build Software.
- Software is broken down into Phases or Planned Major Versions, where deferred features and new requirements will be scheduled for future releases.
- Also, I believe that some good Development Teams know how systems “should” work, and therefore some features requested by the users may end up being put into the system in a radically different fashion then originally envisioned by the Business Community or Business Analysts. However the original need is preserved and perhaps even enhanced to deliver more functionality.
- The Interactive Process does take a lot of trust building, and a lot of time is needed to be spent on getting buy in from the business to allow for things like the deferment and the possible rework of a solution proposed by the Business or Business Analysts.
- Requirements are “refined” by the Users, Business Analysts, and Developers over time, through an iterative review process of the Requirements by both the Business Analysts and Developers.
- In the end it is my believe that the Interactive Approach which in itself is an iterative approach, is the right way to develop software in today’s world. Everyone adds value to the refinement of requirements and the process of Phased Delivery of software produces a better product, especially when there is NO end-state, and the product will continue to be enhanced as the business needs evolve of the period of many years in the case of Enterprise Systems.
In conclusion, I believe the best approach and my preferred approach is the “Interactive Process” to Software Requirements Gathering, and Releasing of those Requirements to Production. I believe in Deferring requiremen and not De-scope of Requirements by the Development teams. There MUST be a Phased Approach to Deliveries, and Refinement of Requirements through an iterative process involving the Users, Business Analysts, and Development Team, is the only real sustainable way of creating medium to large scale enterprise systems and applications.
In my next article I would like to discuss the next segment on “How we Develop Software”, except we will focus on how I believe successful Architects and Software Development Managers Start the Development process, going over things like “component-ize” the source code repository at a high level in-order to create a sustainable code base for the long running enterprise class project.
I hope this article was helpful and as always would appreciate your comments and feedback!Just Another Stream of Random Bits… – Robert C. Ilardi