Philip Hendry's Blog

Designing and Developing Web-Based Applications (Exam 70-547)

Jul 1, 2009 • Notes, • 9 min read

Chapter 1 : Application Requirements and


Before any requirements gathering takes place a feasibility study will probably be performed.

Any application development starts with a Vision defined by the project stakeholders and management. Architects and developers often help business analysts to define the goals and a full set of requirements.

MSF (Microsoft Solutions Framework) for Agile Software Development defines

MSF for CMMI (Capability Maturity Model Integration) defines a requirement work item with a number of subtypes that can be sub-grouped:

Categories of Requirement Definition

Requirements must be defined from multiple perspectives capturing all the needs across the different types of stakeholders. There are a limited number of tags:

Use Cases and Requirements

Typically both Use Cases and Requirements are required for a successful project.

Requirements define what needs to be created for the system to be successful and are useful for:

Use Cases define a set of steps to reach a common user goal and contribute to reaching a requirement.

Evaluating the Requirements

To determine whether the defined requirements are sufficient there are a number of questions that can be asked :

Recommending Technologies

Technology choice should be driven by the requirements. Make it a requirement to use existing technologies if this is valid and justified. A choice of one technology over another should be evaluated against the requirements.

Architecture and technology recommendations are mutually exclusive and should be defined separately. The book suggests technology should be defined first and then combined with the requirements to drive the architecture definition – although I’m not sure that’s strictly the best way.

There are a number of layers that can be considered to break down the technology choice :

Existing Options

Don’t forgot pre-built options that can save time, money and testing:

Creating a High-Level Application Design

At this point there will be:

The high-level application design will explain the application intended to be created and therefore will define the technologies to be used and how they’ll be connected.

Typically this seems to be envisaged by Microsoft as an application diagram created in Visual Studio that highlights the different areas in the system (e.g. web UI, office integration, web services, application services) and the constraints that govern their configuration (e.g. the version of Windows and IIS ASP.NET is installed on.)

Creating Proof-of-Concept Prototype

Design might follow the High-Level Application Design but often it is necessary to produce a prototype to mitigate risk due to requirements missing detail and answer any remaining questions. There should be an expectation that a prototype may feedback on the requirements and change them.

Ultimately a prototype will result in a presentation to the stakeholders and re-enforce the usability, estimated effort, technology recommendation, design challenges and the missing or poor requirements.

There are a number of different types of prototype:

However, there are only two categories of prototype:

Key to a prototypes success is that it answers questions or risks arising from the requirements. For example, there are the following risks:

Chapter 2 : Decompose Specifications for Developers

Creating a Logical Model

The logical is the first step to bridging the gap between documented requirements and a finished application and represents the logical objects, attributes, relationships, and constraints of your domain. The logical model is applied against the technology recommendations and target architecture to create developer specifications (a physical model.)

Logical models should remain fixed unless they’re wrong (!) or the real world concepts, on which they’re based, change. Logical models are independent of architectures and technology.

Object Role Modeling

Entity-Relationship diagrams tend to be primarily associated with databases, and class diagrams are associated to physical, object-oriented development. ORM diagrams are purely logical and allow users, business analysts, and developers to all understand the domain.

Post by: Philip Hendry