I have to document my program for a school project and we have section called "problem domain" but I have no idea what to discuss in this section.
So the question is: What should be discussed in the problem domain?
Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this communityI have to document my program for a school project and we have section called "problem domain" but I have no idea what to discuss in this section.
So the question is: What should be discussed in the problem domain?
I write embedded software for telecommunications equipment. My problem domain is ethernet, voice, and video protocols. In other words, all the stuff that has nothing to do with the language I'm programming in, but that I still must understand in order to write the software. If you're making a website for selling photography services, the problem domain is photography and ecommerce. If you write firmware for military aircraft, the problem domain is weapons, sensors, and control systems. Get the picture?
From the Wikipedia article on problem domain:
A problem domain is the area of expertise or application that needs to be examined to solve a problem. A problem domain is simply looking at only the topics you are interested in, and excluding everything else.
It is the area where the problems your application is intended to solve, belong to.
Not everyone writes compilers, bug trackers, frameworks, or other straight computery software packages.
Some people write software for the sand and gravel industry. Some people write software for monitoring refinery refraction towers. Some people write software to control the manufacturing of plastic grocery bags. Some people write software to fill ketchup packets.
Those are all problem domains, where in order to write good software, you need to know a bit about the domain, e.g. ready-mix concrete.
Ian K. Bray in his book An Introduction to Requirements Engineering (p9) defines the problem domain as the following :
That part of the universe within which the problem exists.
For example, in the case of a lift control system, it would include any existing hardware (lifts, motors, buttons, indicators, sensors, etc.), the building characteristics (number of floors and lift-shafts), the anticipated pattern of usage, the characteristics of the users, the lift usage policy of the client (e.g. should users be discouraged from using a lift for short journeys?) and so on.
Within the lift control problem domain, the problem, as stated above, is, ’a control system is needed that will make more efficient use of the lifts in this building’. In practice, we usually refine the problem into a whole set of sub-problems but, for now, just note that in order to solve the problem(s), it is clearly necessary for the solution system to produce some effects within the problem domain. It is these desired effects that constitute the requirements.
So, the problem domain can equally well be regarded as that part of the world within which the new, solution system (sometimes shortened to SS) will operate and will produce the required effects. Since software-based solution systems are often called applications, the problem domain may be called the application domain.
I see it like this:
The problem domain: The reason the software needs to be built and the environment and industry for which the built system needs to be of use.