Application Requirements

There are many ways to gather application requirements, but in general there are three main areas of focus from which we can choose:

• Data analysis and data flow

• UI design and storyboarding

• Business concept and process analysis

The oldest of the three is the idea that we can design an application by understanding the data it requires, and how that data must flow through the system. While this approach can work, it isn't ideal when trying to work with object-oriented concepts, because it focuses less on business ideas and more on raw data. It's often a very good analysis approach when building applications that follow a data-centric architecture.

Tip 

The data-focused analysis approach often makes it hard to relate to users as well. Very few users understand database diagrams and database concepts, so there's a constant struggle as we translate the business language and concepts into and out of our relational, data-oriented language and concepts.

The idea of basing application analysis around the UI came into vogue in the early to mid 1990s with the rise of rapid application development (RAD) tools such as Visual Basic, PowerBuilder, and Delphi. It was subsequently picked up by the web-development world, though in that environment the term "storyboarding" was often used to describe the process. UI-focused analysis has the benefit that it's very accessible to the end user users find it very easy to relate to the UI and how it will flow.

The drawback to this approach is that there's a tendency for business validation and processing to end up being written directly into the UI. Not that this always happens, but it's a very real problemprimarily because UI-focused analysis frequently revolves around a UI prototype, which includes more and more business logic as the process progresses, until we decide just to use the prototype as the base for our application since so much work has already been done.

Tip 

Obviously, people can resist this trend and make UI-focused design work, but it takes a great deal of discipline. The reality is that a lot of great applications end up crippled because this technique was used.

Another drawback to starting with the UI is that users often see the mocked-up UI in a demonstration, and assume that the application is virtually complete. They don't realize that the bulk of the work comes from the business and data-access logic that must still be created and tested behind the UI. The result is that we're faced with tremendous and unrealistic time pressure to deliver on the application since, from the user's perspective, it's "virtually complete already."

The third option is to focus on business concepts and process flow. This is the middle road in many ways, since it requires an understanding of how the users will interact with the system, the processes that the system must support, and (by extension) the data that must flow through the system to make it all happen. The benefit of this approach is that it's very business focused, allowing both the analyst and the end users to talk the language of business, thereby avoiding computer concepts and terminology. It also lends itself to the creation of object-oriented designs, because the entities and concepts developed during analysis typically turn into objects within the application.

The drawback to this approach is that it doesn't provide the user with the look and feel of the UI, or the graphical reinforcement of how the system will actually work from their perspective. Nor does it produce a clear database design, thereby leaving the database analyst to do more work in order to design the database.

Personally, I use a blend of the business concept and UI approaches. I place the strongest emphasis on the business concept and process flow, while providing key portions of the UI via a prototype, so that the user can get the feel of the system. Since end users have such a hard time relating to database diagrams, I almost never use data-focused analysis techniques, instead leaving the database design process to flow from the other analysis techniques.

In this chapter, we'll make use of the business concept and process-flow techniques. It's difficult to storyboard our application at this stage, because we'll be developing both Windows Forms and Web Forms user interfaces, along with a web-service application interface. Our starting point, then, is to create a set of use-case descriptions based on how the users (or other applications) will interact with our system.

Use Cases

Let's create a set of imaginary use cases for our project-tracking system. In a real application, these would be developed by interviewing key users and other interested parties. The use cases here are for illustration purposes.

Tip 

This application is relatively simple. A real project-tracking system would undoubtedly be more complex, but we need to have something small enough to implement within the context of this book. Remember that all we're doing here is illustrating how to use CSLA .NET to create business objects, child objects, and so forth.

Though not mentioned specifically in the following use cases, we'll be designing this system to accommodate large numbers of users. In Chapter 8, for instance, our Windows Forms UI will use the features of CSLA .NET to run the application in a physical n- tier deployment with an application server. This physical architecture will provide for optimum scalability. In Chapter 9, our Web Forms UI will make use of CSLA .NET's ability to run the application's UI, business logic, and data access all on the web server. Again this provides the highest scaling and best performing configuration, because we can easily add more web servers as needed to support more users.

Project Maintenance

Since this is a project-tracking system, there's no surprise that the application must work with projects. Here are some use cases describing the users' expectations.

Add a Project

A project manager can add projects to the system. Project data must include key information, including the project's name, description, start date, and end date. A project can have a unique project number, but this isn't required and the project manager shouldn't have to deal with it. The project's name is the field by which projects are identified by users, so every project must have a name .

The start and end dates are optional. Many projects are added to the system so that we can keep a list of them even though they haven't started yet. Once a project has been started, it should have a start date, but no end date. When the project is complete, the project manager can enter an end date. We'll be using these dates to report on the average length of our projects, so obviously the end date can't be earlier than the start date.

Every project also has a list of the resources assigned to it (see the "Assigning a Resource" section later in this chapter).

Edit a Project

Project managers can edit any existing projects. The manager chooses from a list of projects, and can then edit that project. They need the ability to change the project's start and end dates, as well as its description. They also need to be able to change the resources assigned to the project (see the "Assigning a Resource" section later in this chapter).

Remove a Project

Project managers or administrators must be able to remove projects. We have no need to keep historical data about deleted projects, so they should be completely removed from the system. The user should just choose from a list of projects, confirm his choice, and the project should be removed.

Resource Maintenance

At this point, we know that the system not only tracks projects, but also tracks the resources assigned to each project. For the purposes of our simple example, the only project resources we'll track are the people assigned to the projects. With further questioning of the users, we can develop a set of use cases revolving around the resources, without reference (yet) to the projects in which they may be involved.

Add a Resource

We don't want to replicate the Human Resources (HR) database, but we can't make use of the HR database because the Human Resources staff won't give us access. We just want to be able to keep track of the people we can assign to our projects. All we care about is the person's name and her employee ID. Obviously, each person must have an employee ID and a valid name.

Resources can be added by project managers or by supervisors. It would be really nice if we could assign a person to a project at the same time as the person is being added to our application (see the "Assigning a Resource" section later in this chapter).

Edit a Resource

Sometimes, a name is entered incorrectly and needs to be fixed, so project managers and supervisors need to be able to change the name.

Remove a Resource

When an employee is let go or moves to another division, we want to be able to remove him from our system. Project managers, supervisors, and administrators should be able to do this. Once they're gone, we don't need any historical information, so they should be totally removed.

Assigning a Resource

As we were talking to the users to gather information about the previous use cases, the users walked through the requirements for assigning resources to projects. Since this process is common across several other processes, we can centralize it into a use case that's referenced from the others.

The project managers and supervisors need to be able to assign a resource to a project. When we do this, we need to indicate the role that the resource is playing in the project. We have a list of the roles, but we might need to change the list in the future. We also want to know when the resource was assigned to the project.

Sometimes, a resource will switch from one role to another, so we need to be able to change the role at any time. Equally, a resource can be assigned to several projects at one time. (We often have people working part-time on several projects at once.)

Lastly, we need to be able to remove an assignment. This happens when an employee is let go or moves to another division (see the "Remove a Resource" section earlier in this chapter), but we often move people around from project to project. There's no need to keep track of who used to be on a project, because we only use this system for tracking current projects and the resources assigned to them right now.

External Access

During conversations with users, we discovered that a number of them are highly technical, and are already skeptical of our ability to create all the UI options they desire . They indicated high interest in having programmatic access to the database, or to our business objects. In other words, we have some power users who are used to programming in Access and know a bit of VB 6, and they want to write their own reports , and maybe their own data entry routines.

Tip 

This same scenario would play out if we wanted to provide access to our application to business partners , customers, vendors , or any external application that's outside our immediate control.

Obviously, there are serious issues with giving other people access to our database especially read-write access. Unless we want to put all our business logic in stored proceduresmeaning that we get to write all the logic in SQLwe can't safely provide this sort of access.

Likewise, there are issues with providing access to our objects. This is safer in some ways, because our objects implement the business logic and validation, but it's problematic from a maintenance perspective. If other people are writing code to interact directly with our objects, then we can't change our objects without breaking their code. Since they're outside of our control, we're basically forced to say that we'll never change our object model.

Of course, this is totally unrealistic, since we know that there will be future enhancements and requests for changes to the system, which will undoubtedly require changes to our objects. Fortunately, we have web services, which change the equation. If we treat our web services like just another interface (albeit a programmatic one) to our application, we can easily provide access to our application without allowing external programs to interact with our database or our business objects directly.

In Chapter 10, we'll revisit these ideas as we implement a set of web services so that external applications can safely interact with our application.