Part Two - The Details Behind The Problem

Written by Stéphane Richard (Mystikshadows)


Welcome to the 2nd part of this series. I'd like to start by doing a summary of what we talked about in the first part to get you situated. The first thing we did is define our problem (project) which is a financial version of Autocad™ we named FinanceCAD. We also looked at all the complete development cycle and the steps the entail. Next we described the different types of software engineering methods we had at our disposal to go about describing the problem at hand. Finally we started describing the project briefly and elaborated the right set of software engineering tools we'll be using to define the problem at the analysis phase of the development cycle.

In this second part of the series, we'll take it from where we stopped in the first part, we'll take the problem one step closer to it's solution by explaining everything that would happen in the analysis phase and see what documents are produced from that step.


Indeed, we can actually talk about what happens next because we now covered what happens first. So then, what does happen next? Do we jump right into the software engineering tool and get busy? The answer has to be no, for more than one reason. The main reason however is that you need to know what you'll be elaborating when you do use that tool. Going live into the modelling tool and starting to get everything into shape is like using the AdHoc software engineering method. You go in without a clear idea of what it is exactly that you are modelling so you model and create documentation after which is the backwards approach to software Engineering. At this point there are still things that need to be figured out before you can start the official modeling technique.

The Analysis Phase is defined by the documents that are needed. Indeed, Analysis means that you are at an unknown or unsure phase of the development. When you start this phase you don't even know if the solution you'll be proposing will be accepted or not and if you won't need to refine your analysis even more than you will be. Starting the modelling phase right away would be a waste of valuable resources at such an early stage. Therefore, let's detail the analysis phase documents so that we can create them. There are essentially 3 documents that should be produced here. These are:

As you can see, there's alot of work involved in the analysis. But when you think of everything that this work will bring to our project, it's very easy to see why this phase should not be overlooked and infact, investing the right time needed to accomplish this phase completely and successfully will help us a great deal in the rest of the development cycle. For the sake of FinanceCAD, we don't need the preliminary analysis since we already got the go ahead to produce the software right in our original email from the boss. So then, let's go about detailing what we can for our detailed analysis document.

Just remember that in the solution proposal document is where you should mention any kind of time related or cost related constraints. These constraints should be made clear, usually in their own seperate and independant sections. These constraint will greatly affect what happens in the rest of the development cycle so they should be made known as early as possible. Such things that they could affect are, for example, the number of employees you might need to assign to the project to assure that the project is done within the time constraint. Likewise, to fit in a cost constraint, you might want to try to get the most oart of the project done by programmers of lesser experience (and salary) when the tasks are routine and repetetive. This will help fit the project within a predetermined budget. This is why it's important to consider these contraints this early in the development cycle.


Looking at what we've learned so far in this second part, let's put this into practice. The following is a definatly more detailed explanation of FinanceCAD. Although this description will be detailed, you have to remember that the description, at this phase shouldn't contain specific programming concerns or issues but rather should server the purpose of describing FinanceCAD in all it's steps it makes available to the user in order to accomplish a complete task which is to produce a design and a list of materials, quantities and prices.


FinanceCAD will be an industrial design application that will allow the user to create house plans according to local design standards. The main goal of the design section of FinanceCAD is to offer a set of commands that the user can either type in using some sort of command prompt or select from a menu depending on his or her background. The application will need to fully support the mouse and the keyboard to accomodate how the user would typically work. This application will need to have specific functionality while and after the design of a house or part of a house is completed to allow to attach materials to the design and calculate prices. Because of the fast changing prices of many construction materials, FinanceCAD will need to allow to change the current prices whenever the user notices a change in the current prices. The design mode will need to work with design layers so that Items can be added to the different layers based on the user's discretion or some set of rules, this will allow for a design firm to establish design standards that their employees will be able to follow easily. Here are the major features of the application categorized in functional groups.


Design mode features are features that are available to the user while he or she are in the process of creating a design. The design mode is the central part of FinanceCAD as in this section is where all other parts of the application can be accessed from. This would typically mean that the user would setup a new design or load an existing one as a first step. Then the rest of the feature would be available.


Database features are needed as many designers could have the need to work on the same design for whichever given reason. Hence Some database features are in order to allow for two users to work on a project in a very safe environment.


In most firms today, a network is present and used at the firm's best advantage. FinanceCAD should not be an exception to this. In a typical network setup, all employees have access to their user space on the main server as well as a shared drive or folder where anyone can have access (good to communicate files between users). Typically designs are file driven as in each design is saved under it's own filename. The database that works around the design file need to be centralized so that management can oversee production of the design from any given location on the network. Therefore, the following network features and considerations are required.


Indeed, because of the nature of FinanceCAD, there is a definate set of features that are mandatory for the proper usage of the printers available to the users. These features are there to allow flexibility to the user when printing a design and it's report as well as save time (and consequently money) by not needing to wait for a printer if it's not currently available. These features are:


In todays world, it seems that if an application of any kind is to be made successful, it will need to be made to work with a broad variety of other applications that can help the user in his or her many tasks. For example, if a design is created for a client, but that client doesn't have the software and would like to see the design in the software they use, then an export could/should be made available to allow the customer to see the given design. As such, here are the major compatibility features that would be required.


The selected target operating system for FinanceCAD will be Windows XP. However, many design firms work with PowerPCs computers and others with the Linux operating system. Each of these work differently and are based on different sets of standards. Likewise, there is the strong possibility of porting FinanceCAD to those other operating systems. Because of these, the following features should be considered:


As you can see, this analysis is, as promised, more complete than the brief description I gave you in the first part of this series. It is not quite complete for a detailed analysis but I didn't want to bore you to death with a 200 page book to read. It's important that you take note that this analysis does cover alot of bases. It does give a good overview of things you might need to consider in your own projects when determining what the application can or should do. This is how this analysis should be taken. You'll find that in most projects of any considerable sizes you will probably find yourself covering the features and feature categories I've described here so you might want to take this list as a "check list" of things to watch out for, and things that will need answers in your analysis process. Everything but some of the reporting features listed here can apply to any type of development project so I think it's a good example even if it's not as detailed as it should be, it should still prove to be a great list to build the detailed analysis with.

In our case here, because we are creating a software based on another software, there are many questions that don't really need to be asked in this scenario. However in the case where you are automating a manual process of any kind, The sample analysis above should still give you a pretty complete list of things that you'll need to consider and elaborate on.


And this concludes the second part of this series. We've covered alot of ground so far and there's still alot to be done in the rest of this series. In the next part of the series, we'll conver everything there is to know about the conceptualization phase in all it's glory and details so to speak. this way you'll know what to expect at that phase too which is the purpose of this series to prepare you in the case such a big project is assigned to you so you don't loose your nerves and your last meal in the process. Happy reading, and see you then.

Remember that I am always open for suggestions on everything that I write, if you have ideas and suggestions about this series, drop me an email and let me know about it so we can make sure that you get the best documents and techniques that you can get.

Stéphane Richard