GoAlfred Blog

Should a project plan be based on requirements, use cases, or subsystems? Not an easy question to answer. After thinking a while about it, I come to the conclusion that it is not based on one of them but based on all of them, depending on what phase the project is in.

In the inception phase, the planning can't be based yet on one of these artifacts, since we don't know yet what will be in the release. The planning can only be based on general tasks such as elicit stake holder requests, identify requirements, ... The outcome of this phase is a clear and agreed list of requirements that will be included in the release. So requirement descriptions are limited to brief descriptions, just to make sure that all stakeholders have the same understanding of the requirements.

For the elaboration phase, it will depend on what elaboration iteration you are in. In a first iteration, you typically (for the selected requirements) try to find the new use cases, identify existing use cases that are impacted, identify the non-functional requirements that need a detailed elaboration, and assess the architectural impact. In this iteration you don't yet elaborate the use cases but limit the work to finding good use-case names and describing them briefly. So this first elaboration iteration will also be planned more task oriented.

After this first elaboration iteration, you should have a good view of use cases and non-functional requirements that need elaboration. In the second elaboration iteration you make a detailed description for them and do analysis and design of them (updating analysis and design models). This is best planned based on use cases and non-functional requirements. At the end of elaboration, it should be clear what changes of existing subsystems (components) and what new subsystems are required. At this stage you are able to make a detailed construction plan, planning different construction iterations.

Planning the construction iterations is the most complex since you also need to consider a logical order of doing the changes to existing subsystems and a logical order based on subsystem dependencies (first do the lower subsystems). Therefore, construction iterations are typically planned subsystem based. However, it can be that you still leave in the dimension of use cases or non-functional requirements for cases where you want to align your construction iterations with delivering completed use cases or non-functional requirements. Note that these type of construction iterations can only be planned in parallel if no changes are required in the same subsystems (or at least changes to a particular subsystem can be isolated or synchronized).

It is not always clear when to use a use case and when not to use a use case. If a use case is used, how and what should be described in the use case?

A use case can only be used to describe a specific usage of the system. The use case clearly describes the interaction of an actor with the system: it is a sequence of "the actor does this, the system does that". An actor can be human (user) or non-human (hardware device). It is important that the actor can only be something that is outside of the system boundaries: it can't be a subsystem of the system.

The description of the flow of a use case should be limited to describing the interaction of the actor with the system. It should not include lengthy specifications related to a specific use case step. For example, when the use case flow states "the system shows display system information", the specification of the "display system information" is best done outside of the flow.

If this non-functional specification is related only to one use case, it can be added in the section of the use case document describing the non-functional specifications, for example under a heading "Display System Information". If the specification is relevant to more than one use case it can be added as a requirement of the system, for example "The system must provide display system information". The detailed specification of the requirement then describes the "display system information" in detail.

The Improving Web Services Security guide shows you how to improve security for your WCF services. It also shows you how to effectively design your authentication, authorization, and communication strategies for WCF. The guidance is task-based and presented in the following parts:

• Part I - Security Fundamentals for Web Services gives you a quick overview of fundamental security concepts as they relate to services, service-oriented design, and Service-Oriented Architecture (SOA.)
• Part II - WCF Security Fundamentals gives you a firm foundation in key WCF security concepts, with special attention on authentication, authorization, and secure communication, as well as WCF binding configurations.
• Part III - Intranet Application Scenarios shows you a set of end-to-end Intranet application scenarios that you can use to jumpstart your application architecture designs with a focus on authentication, authorization, and communication from a WCF perspective for your intranet.
• Part IV - Internet Application Scenarios shows a set of end-to-end Internet application scenarios that you can use to jumpstart your application architecture design for the Internet.

Microsoft Sync Framework is a comprehensive synchronization platform that enables collaboration and offline access for applications, services and devices. It features technologies and tools that enable roaming, sharing, and taking data offline. Using Microsoft Sync Framework, developers can build sync ecosystems that integrate any application, with any data from any store using any protocol over any network.

A key aspect of the Microsoft Sync Framework is the ability to create custom synchronization providers. A provider is a software component that represents a replica for synchronization. A replica is a particular repository of information to be synchronized, such as a file system on a handheld device. When representing a data source, a provider enumerates changes from its replica. When representing a destination, a provider applies changes to its replica. If the data at the source and destination differ in type or schema, each provider performs any necessary mapping or transformation.

Pdftk is a command-line tool for doing everyday things with PDF documents:

• Merge PDF documents
• Split PDF pages into a new document
• Fill PDF forms with FDF data and/or flatten forms
• Apply a background watermark
• ...

Pdftk allows you to manipulate PDF easily and freely. It does not require Acrobat, and it runs on Windows, Linux, Mac OS X, FreeBSD and Solaris.  Pdftk is free software (GPL).

Recently Microsoft released the source code for portions of the .NET framework to VS 2008 users. Fortunately for those still using VS 2005, Kerem Kusmezer and John Robbins built a tool that gives them access to it as well. This tool also speeds up VS 2008 by caching all the source code at one time.

Scott Guthrie recently outlined some of the changes developers can expect when building .NET 3.5 Windows Client applications.  These changes will be released over the next few months.

Web 2.0 is at the center of a wave of excitement concerning how enterprises—commercial or public organisations—are trying to exploit the current generation of Internet technologies. This four-part article series examines aspects of Web 2.0 relevant to the enterprise. In this first installment, take a look at the business and technical drivers behind Web 2.0, the challenges and opportunities Web 2.0 presents to enterprises, and the relationship between Web 2.0 and Service-Oriented Architecture (SOA).

In case you missed them over the past year, here is a round-up of the most popular features and technical articles recently published in The Rational Edge. Please take a look at the archives, either by category or by date, to find more content to help you in your understanding of software development concepts.