I am designing your software solution, not mine. That may appear obvious, but often times a particular solution fits the designer's requirements instead of their client. Why does this happen? Is the designer simply being lazy, or even worse - devious? Of course not. In most cases, it comes down to miscommunication. 

It is easy to get certain details about your project wrong, and then build the wrong solution. Worse yet, if the information you are presented with is hard to visualize, you may even approve the wrong solution. That is what I try to avoid during the design stage. My goal is to present the design of your software in a format you and your team can visualize. That way, if we do have a misunderstanding in one area, it will jump out at you.  Okay, let's take a look at our software design services, and see how we go about building your software solution . 

Prototyping

Instead of relying purely on written documents (Functional Specs, Wire Frames, etc.) which can be hard to visualize, I build a functioning prototype using Serena Prototype Composer. Far more than just a series of pretty pictures, a functioning prototype allows you and your team to fully understand the flow of the application we are building. You can even enter sample data into the prototype to verify that it works as desired.   

Here's a typical screen shot of swim lanes (how different users interact with the system):

Data Modeling

Of course software design requires more than prototyping. The database system also must be designed, and for this task I prefer to use ER Diagrams and Data Dictionaries. An ER (Entity Relationship) Diagram shows the tables within the system, and how they relate to each other. Without going into too much detail, here's a screen shot.

Pretty ugly, I know. I've purposely made the image small enough so you cannot make out the actual names (the actual client appreciates that) but the names for each entity don't really matter. But understanding the relationship between entities is the whole point. That's why they call them relational database systems.  It's an important part of our software design services, since we build a lot of systems geared around databases.

System Architecture

When we talk about system architecture, we are referring to how the system will be structured, and how it will behave. It's a conceptual view of the system. We're also trying to map the functionality with the hardware and software within the system. All these pieces (and more) come together to form the basis of our software design services.