Business Analysis is one of the most important steps in developing a software solution. It is crucial in identifying your business needs and the needs of other stakeholders in order to determine appropriate solutions to your business problems.
We grasp the importance of understanding and documenting business requirements and work with you to gather requirements and formulate business specifications, translating them into application functionality.
EXE Software has a team of experienced, talented business analysts who will formulate a customized business solution based on your requirements. They provide the process, questions, and techniques to efficiently extract the information needed from the Business Users for successful development of projects.
We follow a structured business analysis process:
- Understanding the business
- Defining and scoping the project
- Gathering requirements
- Analyzing and documenting requirements
- Communicating requirements
- Identifying a solution
- Verifying that the solution meets the requirements
Our Business Analysis services include:
Project Scope Document
Before starting to gather the actual requirements, a business analyst needs to ensure that the scope of the project is clear and complete. This involves understanding why the project has been initiated and what the goals of the project are. A complete project scope will name and define all the entities involved with the project. This includes people, systems, internal departments, vendors and customers. It should also include a high-level description of the business processes to be covered as part of the solution and a list of items that will not be included.
A project scope document includes the following:
- Vision and Statement of Purpose
- Project Objectives
- Project Viewpoint
- Project Assumptions
- Project External Interactions
- Suggestions and Recommendations
- Implementation Options
- Business Risks vs. Rewards
- Competition Analysis
Process Flow Charts
Flow charts are an important tool for the improvement of processes. By providing a graphic representation, they help project teams identify the different elements of a process and understand the interrelations among the various steps.
Constructing a flow chart involves the following main steps:
- Define the process and identify the scope of the flow diagram
- Identify project team members to be involved in the construction of the process flow diagram
- Define the different steps involved in the process and the interrelations between the different steps (all team members should help develop and agree upon the different steps of the process);
- Finalize the diagram, involving other concerned stakeholders as needed and making any necessary changes
- Use the flow diagram and continuously update it as needed.
Software Requirements Specifications (SRS)
The SRS document states in precise and explicit language those functions and capabilities a software system (i.e., a software application, an eCommerce Web site, and so on) must provide.
The SRS document also states any required constraints by which the system must abide.
The SRS functions as a blueprint for completing a project with as little cost growth as possible, as well.
The SRS document includes the following topics that must be addressed:
- Interfaces
- Functional Capabilities
- Performance Levels
- Data Structures/Elements
- Safety
- Reliability
- Security/Privacy
- Quality
- Constraints and Limitations
Use Cases Document (UCD)
- The use case document describes what the users achieve by interacting with the system.
- It is one of the most common practices for capturing functional requirements.
- A use case will:
- Describe what the system does so that the user to should achieve a particular goal.
- Include no implementation-specific language.
- Be at the appropriate level of detail.
- Not include detail regarding user interfaces and screens. This is done in user-interface design.
Prototyping
Often the end users may not be able to provide a complete set of application objectives, detailed input, processing, or output requirements in the initial stage.
The cycle starts by listening to the user, followed by building a mock-up, and letting the user test the mock-up.
After the user evaluation, another prototype will be built based on feedback from users, and again the cycle returns to client evaluation.
Prototypes will not work as programs or units, but will provide the visual representation of a possibly real product.