Skip to content

Article: Validating Software Requirements

Unit testing and test driven design don’t help you if your requirements aren’t right. It may be that trying to create the tests will expose that you have a problem but wouldn’t it be nice to know that there are gaps in requirements before you sit down to write code? Although it’s impossible to get perfect requirements, most developers would love to get requirements that are better than what they’re getting.

Whether you’re getting requirements from a business analyst or you’re creating them yourself, here are a few simple tips for ensuring that your software requirements are right. These tips are pulled from my Pluralsight course Gathering Good Requirements for Developers.

Ensurance

Here are some things that you should check to ensure they have been covered:

  • Are all the stakeholders represented? Have you received feedback from all of the parties impacted by the solution?
  • Do you have functional requirements for all user requirements? Were you able to translate all of the high-level user requirements into specific requirements?
  • Do all of the events that the system must respond to have responses? If you look at all of the events such as approvals, rejections, creations, and the like, do they all have a system response?

Read more at http://www.developer.com/design/validating-software-requirements.html

Article: Yammering About Development

Years ago, we heard about a movement in software development that was more about individuals and interactions than processes and tools. It was about responding to change and not a rigid plan. Of course, I’m quoting from the Agile Manifesto.

Agile development didn’t spring to life overnight, but slowly and over time we’ve adapted as an industry a more agile approach to how we develop software. A similar change is happening in the way that we communicate, and it’s happening in the same fits and starts that agile development initially had. The change is about collaboration, not negotiation. It’s about getting things done rather than having documentation. The changes that we’re seeing in communication follow the same openness and transparency that created agile nearly 15 years ago.

One of the tools that stands to change the way that we communicate is Yammer. Microsoft purchased Yammer in 2012 and has been integrating it into its products and services, creating a future that includes Yammer integrated into the Office applications we use every day.

But the question is how does a mass-market enterprise social tools help developers write better software? Clues are in how Yammer aligns to the direction we’ve been headed for years and what we’re already doing in person for agile development. Clues can also be found in the way that we collaborate outside our enterprise, despite Yammer being described as the enterprise social network.

Read more at: http://sdtimes.com/yammering-development/