Business Analysis

project management

At Sumas Corp our Business Analyst acts as a liaison between business people who have a business problem and technology people who know how to create solutions. A Business Analyst’s main responsibility is to gather, analyze, detail, and document requirements in a format that is useful to their business stakeholders and the technical developers. We believe Understanding and documenting business data requirements is a critical component in defining complete requirements. Every process uses data and almost all business rules are enforced by data. Missing a critical piece of data or incorrectly defining a data element contributes to the majority of maintenance problems and results in systems that do not reflect the business needs.

Even the organization has a data administrator or data warehouse team who is responsible for documenting and managing the organization’s information needs, every project uses a subset of that enterprise information in its own unique way. Business analysts must understand the importance of data in all of their projects and include data requirements in their business requirements documentation. Failing to document which data elements need to be used in a calculation, or displayed on a report, leaves the developer the responsibility of choosing the correct pieces of business data from hundreds if not thousands of available fields. These missing requirements often lead to expensive and lengthy project delays during the testing phase. Our Business Analysis Team always follow the core steps in delivering the best analysis report to the organization.

  • Identify and gather the requirements that are critical to the business mission.
  • Interview business stakeholders asking detailed questions.
  • Identify the five core requirements components.
  • Know when a requirement is Excellent.
  • Plan an approach for documenting, categorizing, and packaging requirements.
  • Understand application development methodologies.
  • Verify that requirements are testable and generate testing objectives.
  • Conduct a requirement review.
  • Gather requirements in a group setting by preparing an agenda and managing the group discussion.
  • Identify excellent data requirements at the appropriate level of detail.
  • Detail the data requirements (using a suggested documentation structure and templates in Microsoft Word format or using an Entity Relationship Diagram).
  • Identify and detail attributive, associative and subtype and supertype entities.
  • Detail complex data related business rules.
  • Discriminate between Business Data (Logical Data) and Database Design (Physical Data).
  • Assist with the transition of business data to database design.
  • Utilize easy normalization techniques (without all the mathematical theory).
  • Validate data requirements with activity (process or use case) requirements.
  • Understand and document the business environment using a suggested structure, including detailed templates for defining the Business and Functional Requirements for processes and business rules.
  • Look beyond the current technology or procedures to discover the true nature of the business activity.
  • Ask the right questions to identify the core business processes and the business rules that control or guide them.
  • Document Functional requirements which describe how the software should “behave”
  • Utilize several diagrams including the decomposition diagram, Use Case diagram, and workflow diagrams.
  • Look at the business area from an objective perspective after business requirements are documented and organized to present alternative design solutions that meet the customer needs.
  • validate business processes against data requirements.

Back to Top