Requirements define what software should do. That’s pretty easy to understand. What can be harder to understand is what the requirements actually imply about how the software will behave once its implemented.
Read more...I’m coming to believe that frequent retrospectives may be one of the most important practices to incorporate into the team software development process. Maybe that isn’t too surprising, since this blog is partly inspired by Schön’s work on “reflection-in-action”. A retrospective is essentially “reflection-in-action” for project teams. And it has the same kind of value for a team that individual “reflection-in-action” has: the evaluation of actions and their effects can help you to get better at what you’re trying to do.
Read more...I recently came across an interesting paper that got me thinking about how people naturally explain the kind of complex behaviors we expect from software. The paper is “Studying the Language and Structure in Non-Programmers’ Solutions to Programming Problems”, by John F. Pane, Chotirat “Ann” Ratanamahatana and Brad A. Myers of Carnegie-Mellon University, and is part of CMU’s “Natural Programming” Project. The focus of the paper is on how non-programmers tackle programming tasks. But the findings presented in this paper are probably as, or more, applicable to software functional requirements as they are to software implementation. After all, the audience for functional requirements should include not just experienced software developers, but customers, product owners, testers, and other people who aren’t necessarily attuned to thinking like programmers.
Read more...In a previous note I discussed software functional requirements, and talked about how going back to the basics of software and requirements eventually led me to decide that the Behavior-Driven Development community’s Given/When/Then structure was a good way to define requirements. In that note I talked about the way that “shall” statements, as they’re often used, provide a description of a “timeless truth” about the system (“Aristotle is human”), rather than a description of a dynamic change in the system (“when he gets hungry Aristotle stops thinking deep thoughts and starts eating”). But the purpose of most software (at least the stuff that doesn’t exist just to solve numerical problems) is to be dynamic, so to define its requirements we need a way to describe behavior. In this note I want to explore that notion of describing the behavioral requirements for dynamic systems in a little more depth.
Read more...I’ve been thinking a lot about software requirements lately. Not the most exciting topic, I know. But they’re something I seem to struggle with on a daily basis, and I’ve seen plenty of other people struggle with them too. Yet they’re incredibly important for software development. Having a good set of requirements makes design and implementation so much easier. Even if you’re following an agile approach, reaching a clear definition of done for a user story makes it much easier to know what you’re supposed to implement. So why are they so hard to get right?
Read more...