There are actually methods to the madness in the process of gathering information for software requirements. As a system end-user or a subject matter expert it is likely that you have worked with others during some information gathering processes. Whether it was via a big meeting, or a simple phone call, someone probably has asked you a question or two about what you want the system to be or do. To help you better understand what is being asked of you, here is an overview of the two types of requirements that you are being asked about… Read More
Author Archives: paul.patterson
I’ll be Speaking at EDMUG on September 12 2011
On September 12, 2011 I’ll be speaking at the Edmonton .Net User Group (EDMUG). I’ll be presenting an overview of the recently released Microsoft Visual Studio LightSwitch 2011. RSVP via the EDMUG Meetup site at www.EDMUG.net.
Software Architecture – MVVM Design Pattern Primer
Building a new car requires the input of both a design team and an engineering team. Each team contributes to specific requirements. For example, the design team is responsible for understanding what the consumer wants in the look and feel of the car. The engineering team applies the required mechanics and functionality to the car. Both teams serve distinct purposes, however both teams need to eventually come together to produce what we will eventually drive down the road. Read More
Usage Scenarios – Real World Information Gathering
Let’s say you are a key system user or maybe a business subject matter expert. What would you typically tell someone when you explain what you do to accomplish a specific task? How about if you were to sit down train a new employee on a computer system. What information would you give to that new employee so that the employee can better learn how to do the job that needed to be done?
Just like training a new employee for a job, gathering information for software development projects requires a great deal of diligence. Not enough training, or giving a new employee the wrong information, could have a dramatic effect on how that new employee performs their tasks. Gathering the wrong requirements for a software project would have a dramatic effect on the delivery of a valid solution. Due diligence is required for software project requirements information gathering – making sure that the right solution is created for the right reasons. Read More
Software Architecture – The 4 + 1 View Model
Effectively communicating the same message to the many types of stakeholders in a software development project can be a challenge. Semantics used in a communication, such as that of a software requirement for example, can be received and interpreted differently from one person to the next. Often times each recipient will receive a communication however not everyone will have the same common understanding of what is being said.
There are many methodologies, models, and templates that attempt to provide a more cohesive understanding of a software solution design. The 4 + 1 View Model is one such way of describing a software system. Developed by Philippe Kruchten , currently a professor of software engineering at the University of British Columbia, the 4 + 1 View Model is a framework for presenting a consistent look at the design of a software system.

Save Time and Money with Microsoft Visual Studio LightSwitch 2011
Creating quality line-of-business software applications has never been an easy, nor cheap, proposition for any organization. Larger organizations have the advantage of large budgets and vast resources to mitigate the risks that go along with custom software development projects. Smaller organizations, however, usually can’t afford the time and resources it takes to create the custom software solutions they might need. Building custom software to meet a business need was usually a game that only those in the big leagues could play. Read More


