Here are 10 Best Practices that we follow at Intergy:
- Understanding the Business Context
- Identify Key Stakeholders
- Understand Agile and Waterfall Approach
- Capture Stakeholder Requirements
- Use Visual Aids
- Define Systems and Data requirements
- Review any Regulations and Compliance
- Identify Risks and Constraints
- Document Analysis and Design Document for Customer
- Sign-off
1. Understanding the Business Context
In the realm of custom software development, comprehending the business context is of paramount importance. The goal is to ensure that the resulting software system precisely aligns with the customer’s requirements. To achieve this, a thorough understanding of the customer’s objectives, existing business processes, and potential challenges is imperative. At Intergy, we prioritise this step by dedicating time to work closely with the customer even before project approval. This collaborative effort involves outlining and meticulously documenting the business context. We continually revisit and validate our understanding of this context with the customer. To facilitate this understanding, a range of tools and techniques can be employed, including context diagrams, data flow diagrams, use cases, and entity-relationship diagrams.
DFD - Sample Business Context
Context Diagram
2. Identify Key Stakeholders
Among the initial and pivotal tasks in software development is the identification and engagement of key stakeholders. When we refer to key stakeholders, we encompass individuals from various departments and hierarchical levels within the organisation. Countless projects have encountered setbacks due to the oversight of key stakeholder identification or the failure to engage stakeholders from different departments comprehensively. To gain a comprehensive perspective, it is essential to involve stakeholders from various levels and departments that will utilise or interact with the system under construction. In the case of smaller organisations, this process tends to be straightforward as there are fewer stakeholders to consider. However, in larger organisations characterised by multiple departments and branches, this undertaking can prove challenging. In such instances, a valuable approach is to scrutinise existing systems and business processes. This enables the business analyst to swiftly identify key stakeholders; subsequently engaging with these stakeholders further unveils vital information about current systems and business processes, ultimately aiding in identifying additional key stakeholders.
3. Understand Agile and Waterfall Approach
The choice between Agile and Waterfall methodologies hinges on the specific project and customer preferences. These two principal approaches offer distinct advantages depending on project dynamics. Hence, it is incumbent upon most business analysts to be well-versed in both methodologies.
Agile is characterised by its adaptability and prioritisation of flexibility. It thrives in situations where scope or requirements are subject to frequent changes. An Agile approach enables seamless incorporation of modifications as the project unfolds.
On the other hand, the Waterfall approach presents a structured framework that adheres to a fixed, sequential process. This methodology is apt when there is minimal anticipated change in project requirements, and the customer prefers a fixed-cost approach.
There is no universally superior methodology; the choice is contingent upon the nature of the project and the customer's preferences. Business analysts must be adept at navigating both these methodologies to tailor the approach to the specific needs of each project.
4. Capture Stakeholder Requirements
For any business analyst, capturing requirements is fundamental. It's a task that all business analysts must perform adeptly; the responsibilities of which encompass not only capturing but also interpreting, documenting, and categorising requirements within a comprehensive requirement matrix. Analysts must validate findings and actively solicit continuous feedback from customers. In our experience at Intergy, the most effective approach to gather requirements involves conducting workshops or meetings with small groups or key stakeholders. During these interactions, posing a multitude of both specific and open-ended questions proves invaluable, and where possible, we also request any pre-existing documentation, reports, processes, and relevant materials before initiating workshops or meetings. A preliminary investigation of such materials equips us to conduct more informed and productive sessions. Additionally, it's important to note that when capturing requirements, it’s best to minimise the use of technical jargon. Not all customers possess a technical background, and our aim is to ensure that our communication is universally comprehensible and inclusive.
5. Use Visual Aids
Business analysts can effectively employ visual aids to facilitate the elicitation of requirements from the customer. Domain models can serve as valuable tools for explaining and validating the system's functionality. Various other visual aids, including activity diagrams, UML diagrams, use cases, DFDs (Data Flow Diagrams), ER diagrams, and more, can be utilised for this purpose as well. In our experience at Intergy, incorporating wireframes into the process proves to be particularly beneficial. Wireframes provide customers with a tangible visualisation of the system's appearance, allowing them to grasp its look and feel without investing excessive time in detailed screen designs.
6. Define Sytems and Data Requirements
Following the capture of stakeholder requirements, this step should be undertaken. To define the system and data requirements, we must understand how the system will be utilised, the number of users it will accommodate, the necessary resources, and the expected volume of data, among other factors. In today’s software development landscape, many applications are built on platforms like AWS or Azure, allowing customers to easily adjust memory and resources to meet their needs.
7. Review any Regulations and Compliance
If you’re developing software in a regulated industry, it’s important to understand the relevant industry regulations, compliance requirements, and standards. For instance, software development in sectors such as energy, utilities, or finance necessitates a thorough understanding of industry-specific regulatory demands. Proceeding with system development without this knowledge poses significant risks to both the software developer and the customer.
8. Identify Risks and Constraints
Identifying risks and constraints is a fundamental aspect of every project. It involves discussing potential risks, limitations, and constraints that could impact the software development process or outcomes with the customer. Since project resources are invariably finite, recognising these elements is crucial for ensuring the project stays on schedule, within budget, and with the appropriate resource allocation. For example, a risk might involve a customer’s inability to provide required data by a specified deadline, potentially causing project delays. Another risk might pertain to system security, necessitating encryption for data entering and exiting the system to prevent potential data breaches.
9. Document Analysis and Design Document for Customer
Upon completion of the preceding steps, Intergy compile an Analysis and Design document. This comprehensive document encompasses system design, process descriptions, data and system requirements, and functional specifications. While some organisations maintain separate documents for Analysis, Design, and functional specifications, at Intergy, we integrate all these elements into a single document, streamlining the approval process for our clients.
10. Sign-off
This represents a pivotal phase in custom software development, signifying the formal approval of a project phase by stakeholders. Sign-off indicates the customer’s agreement with the design, requirements, scope, and quality standards, facilitating the progression of the project to its next phase.
