Software Requirements Evolution


Software Requirements are evolving to keep up with users’ demanding appetite for applications. Simple “The system shall” statements have grown into User Stories and Storyboards. It used to be that talking about the GUI was verboten when gathering requirements. We software practitioners knew how to use the magic of creating software and the lowly users just needed to tell us what they needed and we would pull the software solution out of our proverbial hat. Not so anymore. Practically everyone has a smart phone or smart device (even my 3 year old) and the word “app” is universal thanks to the iPhone. Can I really gather requirements from my 3 year old for her new drawing app using Use Cases? Obviously no. Granted,the use cases may be used by the software developers but my 3 year old can’t even read for Christ’s sake.

Most users now know if they want a mobile app, web app, or desktop app. They know the differences and strengths of using these from years of experience. That’s why I think a more agile way of gathering requirements where quick prototypes and storyboards are used to gather feedback are meeting users’ requirements much better. If it’s a web app, well you have obviously constrained the application down to what HTML, JavaScript, CSS, etc. can do. So why not make a quick prototype of that? If they want an iPhone app, well there’s a pretty set style of doing that set by Apple. Obviously, we software professionals still have a part to play by asking, “Are you sure you won’t want to eventually have an app on the Android too?”. This leads to conversations about different architectures, technologies, and the cost/benefit analyses of each. But older ways of doing Software Requirements are becoming decreasingly beneficial with the changing “tech savvy” of users.

Please don’t get me wrong, there are still places to use Use Cases for certain kinds of projects. They are a tool in any good Software Requirements professional’s toolbox. But newer tools are coming out that need to be considered much more to keep up with software professionals’ ever changing user base.

About these ads

Best Practices when customizing Work Items in Team Foundation Server (TFS)


So I’ve been thinking a lot lately about how to customize work items while still making sure the TFS instance is able to upgrade smoothly to future versions. In my Internet research, I actually came upon a good article on this from of all sources, Rational (Microsoft’s main competitor). This is due to the fact that they use almost the exact same data model for work items in their product (Rational Team Concert) as TFS does. They both even call them work items! Anyways, the article does a good job of dividing customization’s into “Safe”, “Cautious”,and “Harmful”. Based on my experience and expertise, these are some good principles to follow when customizing work items in a process template. You don’t want to over customize and be stuck on TFS 2005 for the next 10 years!
Enjoy!

https://jazz.net/library/article/1002

A son is born!


Wanted to post to my blog that my family just had our third child, a son finally! ;) John Dunn Woody was born on February 1st, 2013.

A Review of TeamSpec – a TFS plug-in for MS Word


Two years ago I did an evaluation of TeamSpec and pointed out some areas of improvement. I’m very happy to report that the company took these to heart and updated their product to address these. Here is my updated review based on TeamSpec v.4.2.1.

TeamSpec is a 3rd-party add-in for MS Word that connects it to Team Foundation Server.  It works with the newest version of TFS 2012 and Office (2013).  It is the only commercial add-in for Word currently on the TFS platform. There are other companies that have add-in’s as part of their overall suite or solution, but TeamSpec is the only product to concentrate on just Word and it does it quite well.

How It Works

Work item attributes are linked to sentences or words in your Word Document.  This is a bi-directional sync between TFS and Word.  For example, say you have  a requirement work item with the ID of 3 and the title is “Login to system”.  You could create a line in Word with the tool like so:

REQ ID 3 – Login to System, State: Proposed

When you changed the state of the requirement work item from “Proposed” to “Active” in TFS, the line would change in Word to:

REQ ID 3 – Login to System, State: Active

This could also be done the other way by changing the state in Word and publishing the change to TFS.

Additionally, you can create “Skins” which are basically pre-defined layouts for work items. You could say that you want the state of work items to always be in bold and italicized in a skin for example.

Added Functionality

The new functionality that I really like and makes it a valuable product is the ability to use work item queries from TFS with Word. Writing custom reports in Reporting Services for Word is not easy, especially since the HTML fields are not stored in the TFS Data Warehouse. This product makes it a cinch! No more writing a huge SRS! Just generate it! :)

Linked worked items are supported in queries and test cases are supported as well!!! So you can do your testing documents here as well.

The documentation has improved tremendously, but a few more “behind-the-scenes” articles in the documentation would be nice. I also hold some small reservations about the long term stability of the company as it appears to be small, so be sure to ask for the source code when you buy the product. But to be fair, they have been in business since 2005.

Conclusion

I highly recommend you look at this product if you are using TFS as your ALM platform. Microsoft majorly overlooked Word integration in TFS (although they got Excel and Project), but alas, this is where partners like TeamSolutions step in! Thank you TeamSolutions for stepping in so well!

Use the TFS Process Template used by Microsoft


Found this interesting post that explains the “ISD” process template that is used by Microsoft Consulting Services. I always get asked by customers what Microsoft uses for TFS, well now here’s a process template used by a branch of MS. Enjoy!

An Example Coding Style Guide for .Net


This is a great example of code style guide used by Microsoft for internal coding. I’ve included a sample of it below. Enjoy!!!

All-In-One Code Framework Coding Standards

What is RUP or Rational Unified Process?


So when I went searching for a current definition on RUP, much of the writing on it was at least four years old.  Here is the definition I came up with gathering the most current sources I could.

RUP is made up of three components:

  • Key Principles for Business Driven Decisions
  • A Framework of re-usable method content and process building blocks
  • A underlying Method and Process Definition Language

I will expound on these below.

Key Principles

The following are the key principles behind RUP:

  • Adapt the Process
  • Balance Stakeholder Priorities
  • Collaborate across teams
  • Demo Value Iteratively
  • Elevate level of abstraction
  • Focus continuously on quality

Framework

The framework is made up of best practices that have been used effectively in software development over time (e.g. Use Cases) and “Method Plug-Ins”.  Based on these, organizations develop different flavors of RUP based on:

  • Organization Maturity
  • Project Complexity
  • Organization Culture
  • Regulatory Compliance & Policy Requirements
  • Type of Development (Embedded vs Web App)
  • Organization Size

Method & Process Definition Language

Finally, the actual specification of the process is done in what is called a Unified Method Architecture (UMA) Meta Model.  This included things like phases, disciplines, activities, milestones, etc.

Phases, Milestones, and Disciplines

Finally, an important part of RUP are the phases that you go through and the milestones that are hit as you go through each one.  The below graphic from Shuja and Kreb’s book shows this well:

getfile

Within each of these phases, all of the disciplines are being done, but some more than others depending on the phase.  A discipline is defined in RUP as a collection of related activities.  RUP has the following disciplines:

  • Business Modeling
  • Requirements
  • Configuration and Change Management
  • Analysis and Design
  • Implementation
  • Project Management
  • Test
  • Deployment
  • Environment

The mixture of phases and disciplines leads to the famous “hump chart”:

I will conclude by quickly describing the phases:

Inception Phase

The following activities are done in this phase:

  • Estimate Scope
  • Identify Critical Use Cases
  • Exhibit and Demo one candidate architecture
  • Estimate Cost and Schedule
  • Detailed Estimates for Elaboration Phase
  • Estimate Potential Risks
  • Prepare Support Environment

Elaboration Phase

The following activities are done in this phase:

  • Stabilize Architecture, Requirements, and Plans
  • Mitigate Risks to determine cost and schedule
  • Establish Baseline Architecture
  • Produce Evolutionary Prototype of Production Quality components
  • Optionally do throw-away prototype as needed
  • Establish Support Environment

Construction Phase = Build It!

Transition Phase

These are some of the activities that make up this phase:

  • Beta Testing or User Acceptance Testing
  • Train End Users and Maintainers
  • Fine-tune through bug-fixing and enhancements

I hope this short overview helped you to quickly get up to speed on RUP.  There is certainly much left uncovered here, so if you interested, consult the sources above.

Follow

Get every new post delivered to your Inbox.