Advertisements

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.

Advertisements

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.