What happened to Software Requirements?

As I look out onto the landscape of software currently, something is missing. It’s REQUIREMENTS! 15 years ago, testing was in a similar position. What slipped first in a hurried project? Testing. But then came along Agile, Kent Beck, and xUnit. Testing now has its own methodologies like TDD, BDD, and the like.

Can you imagine if someone created a methodology called “Requirements Driven Development”?!?! They’d be laughed out the door…. 🙂

So why are Requirements being given such short shrift now? They are given lip service from the Agile community at best.

Use Cases? “Oh my god, I’m going to throw up!”

User Stories? “Yeah, just write it on a card, we’ll figure it out later, and make sure to rip it up at the end. That crap is useless.”

Really!?! Are you f’ing kidding me! This stuff matters! Well, it definitely matters when things go south on a Software Project, you know, like “we’re going to court” south. But by then it’s too late. Everyone’s trying to reverse engineer the requirements from the present software. It’s a tragic charade.

So here’s to Software Requirements. They matter. Don’t believe me? Well, when a lawyer asks you, “Was that an enhancement or a bug?” and you answer, “Uh, it was in the user story….”. Well, then we can talk 🙂

Software is everywhere – especially in cars

Amazing article in NY Times talks about how software is taking over everything, even our cars! We can’t see this software and it’s been exposed to hacking (Jeep being driven off the road by remote hacker) and manipulations of emissions tests at Volkswagen. People in the article argue cogently that this code should be made open-source so that we can examine it and know what we are buying as consumers. At the very least, it should go through some of the strict reviews and audits that airplane software goes through. Congress and the federal government should act before something bigger happens than the two examples above forces them to.

Use Case Driven Scrum

In today’s software development community, Use Cases are often frowned upon. A quick search on Google for “Use Cases Scrum” and you quickly find that they are put up against User Stories and quickly lose the fight. I believe in Use Cases because they force stakeholders and the development team to have the right discussions in a structured way. They also expose many things you will not think about when writing requirements in other ways.

But the art of writing Use Cases is dying. “Uncle Bob” Martin has said that it shouldn’t take longer than 15 minutes to teach someone how to write use cases[1]. He’s wrong and unfortunately hyperbolic. But these are the Agile times we live in, when everything invented before the Protestant-like reformation is looked upon as sacrilege.

I believe in Scrum. I think it can wholly benefit organizations with small teams that need to be more nimble or agile. But I don’t think Scrum is exclusive from Use Cases. Here is the definition of a product backlog from the Bible of Scrum, The Scrum Guide:

The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product.

Notice it says requirements. The Scrum Guide does not say how to do requirements (User Stories come from XP), it just says that they need to be in the Product Backlog.

So this is where my proposal for Use Case – Driven Scrum starts. Put your Use Cases in the Product Backlog. Now one of the criticisms of Use Cases is that they are too much documentation and take too long to write. Well, don’t write them out then! Just start by identifying the Use Cases you should do (give only their title). For example, put the Use Case “Log into system” into the backlog, but don’t bother to detail it out at first.

Scrum practitioners know that undefined product backlog items belong at the bottom and as they move up in priority, they become better groomed as the following picture illustrates.

This leads to the second part of my proposal. Refine the Use Cases as they move up the backlog. Add the basic flow or maybe the primary actors. This becomes part of your Product Backlog grooming.

Finally, most full use cases with all their basic and alternative flows will not fit into one sprint. So the final part is to break them down into scenarios that will fit into one sprint. Mind you that use case flows and scenarios are not the same! The basic flow is always a scenario, but mixing in the alternative flows is where it gets interesting. J

The tactics of breaking product backlog items up really depends on the tool you use for tracking your work. Spreadsheets, Rally, and Team Foundation Server all have different ways to do this. I hope you’ve enjoyed this article and would love to hear your feedback below. Good luck in your journeys of software development!

[1] http://alistair.cockburn.us/get/2231

Software Engineering is all about Modelling

There is a great article over at O’reilly entitled “Striking parallels between mathematics and software engineering”. I’ve never really thought about the parallels of Math and Software Engineering. I’ve thought about Civil Engineering, Medicine, and the Law; but not Mathematics. To summarize, the author says that Mathematics is really about modelling and that is what we do in software engineering continually, especially when following object-oriented paradigms. It is striking and has opened my eyes to a whole other avenue to explore when it comes to Software Engineering. Just thought I’d share 🙂

Latest ACM Turing Award Winner Announced!

Lesile Lamport, a Principal Researcher at Microsoft Research, has been announced by the Association for Computing Machinists (ACM) as the winner of the 2013 Turing Award winner. The Turing Award is the equivalent of the Nobel Prize in computing. I always look at these prize winners as “Gods” of the computing world and I think it’s important that we remember and honor our history if we are to progress as a profession. He won it for his his work in distributed computing, which I can tell you from my graduate course, is some very difficult stuff. He also created LaTeX among other things. Congratulations!

Official News Release

What is Software Engineering in the 21st Century?

In February of 2001, 17 people met in Colorado to discuss how to move the Software Engineering discipline forward. They were frustrated that their more lightweight, adaptive methods were not being tried while watching heavier methodologies continue to fail with over budget and over schedule projects. They correctly surmised that a revolution would be needed to make the Software Engineering community hear and, more importantly, implement their solutions.

They could have left in disagreement and disarray over non-essential questions like: What’s better, Scrum or Feature Driven Development? Fortunately for the Software Engineering field, they didn’t. They wrote a Manifesto which is shown below:

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Their Manifesto worked beyond their wildest dreams! Like any revolution, there was resistance, especially in the establishment. But after 10 years, it was clear that they had won the war. The establishment could not resist any more and all discussions on Software Engineering now have to include Agile practices.

After the American Revolution, the American founding fathers were faced with a whole new set of problems that were in many respects bigger and more complex than winning the revolution in the first place. The Agile Revolution finds itself today in a similar situation. Questions such as, “What is the best way to scale Agile to an entire Enterprise?” are what need to be answered today. The Agile movement would be wise to not throw away everything that came before it in Software Engineering, but rather mix and modify it to set our discipline on a new course. This is what the Americans did when they took the King concept, mixed it with democracy, and came up with the modern presidency. I’m looking forward to the next 10 years to see where this mixture leads us!

Why is Healthcare.gov not working? (from a technical perspective)

Most web applications have a architecture like the below. There are of course nuances and exceptions, but for the layperson, this will suffice.

The “Presentation Layer” handles all the graphical packaging of content in web pages presented back to the user. This article in the Atlantic has a good description of the Presentation Layer for Healthcare.gov. This is definitely NOT the problem as pages of just content come back very fast without problems. Clicking 90% of the links in the Healthcare.gov sitemap come back in under a second. BUT, a web application with just a good Presentation Layer is like a book with a nice cover design and nice pictures inside; no one will care if the text is not good. The rest of the Healthcare.gov web application is the text and is seems to be horribly bad at the moment.

The next part of the system is the “Business Logic” layer. In Healthcare.gov this is called the “Data Hub” and is described here. There is a tremendous amount of coordination between different web services (Social Security Administration, IRS, Insurers, etc.) to make sure you get the insurance you’re supposed to. Unfortunately, this is where the software engineers for Healthcare.gov have the least control over what happens, because they are dependent on these other services to relay data back to them quickly.

Finally, we have the “Data Access Layer” and “Data Source”. This is where all the data is stored (e.g. your name, address, age, etc.). The data that Healthcare.gov has to collect and then connect to other relevant pieces is tremendously complex and it is very possible that many of the problems lie here as well. Fortunately, this is one place where you can “throw more servers at the problem” to alleviate performance problems somewhat.

While the answer to the question why healthcare.gov is failing is not entirely clear, I hope you have gained an appreciation for the complexity of this very important web application and how one problem in any of it parts can make the whole application slow down. Unfortunately, I predict that many of these problems will not be fixed quickly because of their logical complexity. Throwing servers at the system will only alleviate a small percentage of the problems and ultimately does not substitute for quality software. Throwing more people at this problem violates one of the few laws we have in Software Engineering — “adding manpower to a late software project makes it later”.

So, What is Requirements Work?

Interesting article from the Spring Issue of IEEE Software entitled, “So, What is Requirements Work?”. The author, an obvious expert in the field, goes on to conclude that Requirements Work is basically helping people help themselves. I like this definition. As a Requirements Analyst, you cannot know every single domain you will be parachuted into as your career progresses. No one can be an expert in Medicine, Law, Accounting, Botany, etc. Instead, “smart” Requirements Analysts depend on the domain experts that already exist to guide them to the problems that need to be solved. Then, they are able to get out of domain experts/stakeholders the specifications of those problems. Finally, the requirements analyst can specify those requirements in formats that are decipherable by multiple stakeholders (developers, customers, etc.).

I’m not sure I agree that Requirements Work involves coming up with solutions though. It seems to violate some central core of Requirements that were taught to me, “Concentrate on the problem, not the solution.” But, I’ll admit as a former software developer, I can’t help to think of solutions when I hear problems. I have to be judicious, though, about when I bring them up.

Check the article out yourself when you get the chance!

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.

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!