Concept development

Concept development is concerned mostly with fleshing out some of the high-level details that come out of the initial concept, providing details and direction for efforts later in the life cycle. One of the more significant aspects of this step is the generation of various System Modeling artifacts—and there's enough involved in those efforts that they'll be covered in a separate chapter. The balance of the development-related information that comes out of this phase is probably focused more on marrying business processes and system functionality, and providing some detail around system goals. There is also room here for a definition of at least a basic user experience and/or user interface, especially as they connect to the process/functionality.

Defining the business processes embedded in a system includes identifying the business objects that the system keeps track of, the actions that can be taken with respect to those objects, and the outcomes of those actions, at a minimum. Applying of the sort of questioning described earlier in Chapter 1, Programming versus Software Engineering, can yield a fair bit of that information, if more detail is needed.

By way of example, consider a system whose concept begins with the knowledge that they need a way to keep track of fuel efficiency across their delivery truck fleet. Working out the business objects and activities from there could answer some very basic questions, such as the following:

• What is the system keeping track of?: The individual trucks in the fleet, the mileage on the odometers of those trucks at irregular intervals, and the refueling of those trucks, at a minimum.
• What does a refueling look like?: A fuel quantity and the odometer reading at the time of refueling, to start with. Those two data points would allow for the calculation of fuel efficiency, which is calculated in whatever units each uses (gallons or liters for fuel, miles or kilometers for the odometer). Fuel efficiency becomes a calculation of any given refueling for any given truck, and the current odometer reading for any given truck can be retrieved from the odometer reading at its last refueling.

• How many refuelings should be kept for any given truck?: If one of the goals of the system is to detect when a truck's fuel efficiency has dropped, in order to flag it for maintenance, perhaps, or to trigger a review of the delivery scheduling associated with it, then there is an obvious need to keep track of more than one such refueling—maybe all of them.
• Who will be using the system, how, and where?: There would need to be at least two types of physical access point: one from mobile devices (when fueling a truck), and one from in-office computers (for reporting purposes, if nothing else). That set of use cases tells us that we're looking at either a web application, or some sort of dedicated phone and computer application set, with access to some common data stores, possibly through a service layer.

There may be other questions that could be asked, but these four alone probably give enough information to make the most of major concept design decisions, though the latter may require a bit more exploration before they can be finalized. Similar questioning, asking things such as What can (a specific type of user) do with the system until there aren't any more users and activities, can also yield more specific system goals:

• Various users can log refuelings, providing the current odometer reading, and the quantity of fuel involved:
  
  • Delivery drivers (at local fuel stations)
  • Fleet maintenance staff (at the main office, where there is a company fuel station)
• Fleet maintenance staff will be alerted when a truck's calculated fuel efficiency drops to lower than 90% of its average, so that the truck can be scheduled for an examination
• Office staff will also be alerted when a truck's calculated fuel efficiency drops to lower than 90% of its average, so that the truck's delivery rounds can be examined

The question of how and where users will interact with the system may well spark some discussion and design decisions around user experience and interface design as well. In this case, perhaps after discussion about whether the system is a web application or dedicated phone and desktop application, the decision is made to make it a web application and to use the Clarity Design System for the UI, because the primary stakeholder in the system's vision likes the way it handles on-screen cards: