Business Analysis Training Lesson: What are the System Context and the System Boundary?
This lesson is part of a series of sample online Business Analysis Training lessons. You can enrol for the COMPLETE IREB® CPRE® Foundation Level Syllabus aligned version of this course below. The COMPLETE course includes tutor support, assignments, quizzes and case studies to apply your knowledge and understanding. Recommended for IREB® CPRE® Foundation Level Certification Exam Preparation.
ENROL NOW – ONLY AUD$49.90
Business Analysis Training Lesson
Welcome to this Business Analysis Training Course. This lesson is an introduction to System and Context Boundaries in terms of Requirements Engineering. Today we will cover the topic of system and context boundaries. Also watch the video to learn more about the fundamentals of system and context boundaries.
What is a System Context?
Let’s start with what we mean with the concept of “system context”. The easiest way to understand what is meant by system context is to consider an example. Let’s say we hear that the Human Resources department wants to implement a new Human Resources Management system. The definition of the system context in this case is influenced by a variety of different aspects within the Human Resources arena. Let’s consider each aspect one by one:
- People – an example of the people who can form part of the definition of your system context include the HR Manager, Recruitment Consultants or anyone else in the organisation that works with or is impacted by the Human Resources system.
- Systems in operation – an example of this could be an existing system that may be used in the Human Resources department that needs to be replaced. The system in operation will be a key part of your requirements engineering work and therefore must form part of your system context.
- Processes – in the example of the Human Resources context you would need to consider business processes such as: Recruitment, Performance Management, Payroll and Records Management. These business processes all have valuable information to help you define the requirements for the Human Resources system and is therefore part of the system context.
- Events – technical or physical events can help define the requirements systems context as well. Examples of these types of events could be that a certain technical infrastructure change throughout the company at a certain time during your project could have a direct impact on your requirements. This means that you should include that technical event’s detail into the system context you have to consider when defining your requirements.
- Documents are another aspect that could form part of your system context. In the example of the Human Resources system you would need to include the legal policies and procedures that exist with the employment law of the country. This aspect therefore also forms part of your systems context when defining your requirements.
In summary, you should include all these aspects when you define your system context in order to make sure that your requirements engineering work can be complete and accurate. It is quite crucial to consider all these aspects in the definition of the system context to ensure completeness. You must also ensure that you define your system context very clearly to enable the understanding of all your requirements in the correct context.
What is the System and Context Boundaries?
In order to define the system context for your requirements efforts, you must define the system boundary and the context boundary. Let’s look at what each of these boundaries represents:
Defining the system boundary is all about making a decision about which aspects pertain to the system to be developed and which aspects belong in the system context. In the example of the Human Resources System: Consider which aspects is part of the Human Resources system and which parts are only informing the requirements for the system. The Human Resources system need to include all the functionality that is currently available in the current system but the system doesn’t manage employment contracts. Therefore, the employment contracts are outside the system boundary but the current system’s functionality must be replicated and is inside the system boundary.
Now let’s look at defining the context boundary: The decision you have to make here is whether the aspect you are considering is within the context of the system or whether it is not relevant at all to the planned system. For example: In the Human Resources system example, the employment contracts is relevant to the Human Resources system and is therefore within the context boundary of the requirements efforts. However, if you consider the fact that the organisation will be upgrading their printers at the same time of your project, you will place this outside the context boundary because this has no impact and is completely irrelevant to your requirements for the Human Resources system.
If you are able to consider these decisions about the system and context boundary when you consider all the key aspects (people, process, systems, events and documents), you will be defining your system context with ease and clarity.
To do the complete online Business Analysis Training course with us, enrol for the Micro Course 1: Introduction to Requirements Engineering – only AUD$49.50