How Do They Develop Software Anyway? (Part 1) Let's start with requirements.
The purpose of the requirements phase is to facilitate communication
between the Business and IT. The deliverable due at the end of this
phase is the Business Requirements Document (BRD). The BRD represents
the contract between the two groups identifying what the Business wants
and when IT can deliver it.
This phase identifies the scope of work, functional and non-functional
requirements and the stakeholders for the project. At this point in the
project it is important to focus on first understanding the “as-is”
state of the business process/application. IT must understand how the
system works today as a baseline. Afterwards, the Business can begin
identifying a wish-list of functional enhancements for the “to-be” state
of the application.
The basic flow for this phase is for the project owners to help identify
scope and stakeholders. IT then will engage the business to understand
high level process mappings. During that activity IT will construct
entity relationship diagrams to understand how the business entities
relate to one another within the domain space. Then IT will construct a
process flow diagram to understand how the overall process is broken
down into subsequent steps performed by specific business entities.
After finding out how to represent the system in today’s world. The
Business then starts to identify their requirements for the project.
These requirements will take the form of functional (e.g. click a button
and it does something) and non-functional (e.g. there will be 100
people using the system concurrently) specifications. The Business
Analyst (BA) will capture these requirements and document them in the
BRD and eventually the requirements will be tracked in the Eventum
application. In addition, the BA will capture the context of these
requirements with the help of Use Cases and Screen Shot Mockups. A Use
Case helps identify who is performing work and how it flows through the
“to-be” system. The Screen Shots help visualize the changes/enhancements
to various graphical user interfaces.
Overall this phase will help frame the next phase design and
architecture. There the IT Architects will determine how to bridge the
gap of the “as-is” system and the “to-be” system. If any requirements
change beyond the requirements phase then the updated requirements must
go through a change control process. Please view the Change Control
section for more information. Once the tollgate requirements have been
satisfied and management sign-off is acquired the design and
architecture phase may begin.
