Requirements Engineering & Scope Management

If you are looking for a software or hardware solution to help you perform a task or activity, then it’s time to talk requirements with us. Requirements engineering  is a multiphase approach that starts with understanding and/or establishing a repeatable business process that aligns, adhere and are driven by laws, policies, and regulations. In addition to business requirements other types of requirements such as, functional, technical, data, security, environment, software and hardware, scalability, maintainability, serviceability among other types must be considered.

What are Requirements?

HIT is renowned and highly specialized in this area and we understand the interconnectivities between the enterprise and the system, the interconnectivities between the phases of the SDLC and each release, scope and how all can positively and negatively affect one-another.

Requirements-gathering is as much an art as it is a science and it must be done precisely and accurately. Requirements are the foundation of a system and the users’ desired functionality requesrs. It is critical to gather, manage, control, and implement them is a deliberate manner to ensure the desired outcome demonstrated by an application’s features and capabilities.

A requirement or a group of requirements typically state an application’s or a system’s business process “activities” it must perform. Earlier, we mentioned different types of requirements; we must also mention that a requirement can be general, high level, at a process level or lower at an activity level.

Approach and Methodologies:

HIT has a highly flexible and effective approach to gathering requirements. We understand the challenge our clients face in knowing their requirements and realize the unlikeliness of knowing all of their requirements – however, this is hardly ever the case.

Our approach at HIT is to work with our clients and conduct our SDLC analysis and planning phase to define and determine what is feasible and meets their business needs. We will then work towards establishing a robust process tailored to your business needs and conduct our gathering phase activities. We will follow and continue to define, document, manage, control phases of our requirements gathering processes which will prevent scope creep, help establish appropriate levels of application releases, and produce the right level of artifacts for the consumption of Development, Test, CM and Release Management teams, such as RTM, SRS, FRD, Use cases, Scenarios, Epics, User Stories, etc…as needed.

HIT is fully equipped with the knowledge of the Agile or traditional methodologies and work frames of requirements gathering, management and delivery. Our team leads are certified INCOSE requirements engineers and Agile SCRUM Masters, while our practitioners are fully trained in these disciplines. We are confident in getting the job done right every time, and the first time.

Requirements tools:

Tools are ideal as they allow for easier requirements management and help establish the interconnectivities between other phases of the development life cycle. However, we understand that often they are not attainable, licensing issues, types, costs are among some of the reasons. We will work with you and recommend a tool that will meet your need and a tool that build efficiencies and speed in the task’s execution.

HIT has delivered, conducted and is fully capable of gathering, documenting, managing and controlling system requirements regardless of using a tool or in its absence. We will work and partner with our clients to establish the right combination of templates, phases, approach, governance, management and delivery uniquely tailored for each project. Some of the ways to establish requirements are:

  • Forward Engineering and Reverse Engineering
  • UML Models
  • Decision Models
  • Business Process Models (BPMN)
  • Data Models (Conceptual)
  • Use Cases – Tailored per project need
  • EPIC/User Scenarios/Stories
  • Functional Decomposition
  • Top-down or bottom-up
  • Business Rules
  • Acceptance Criteria