Does BYO Make Sense for Utilization Review Software? Part 5: Document Requirements, Design and Code

| | Technology & Integration, UR Software

FacebookTwitterGoogle+LinkedInEmail
Todds Build Your Own Software Series Graphic V 3 Copyright Free

At this point in the Software Development Life Cycle (SDLC), you’ve put a lot of work into deciding what to build. Now it’s time to build it! The next step is to create formal requirements. You’ll need to take all your notes about workflow, usability and use cases, and build a set of requirements that the software developers need in order to start building. This generally starts out with storyboarding, similar to how movies are created.

Begin by drawing and labeling squares that represent each screen of the application. For each screen, document the information needed and the actions you want the user to be able to do:

• What data they need to enter

• How that data ties into other areas of the system

• How the data should be validated

Next, review your use cases and document how the user is expected to interact:

• What happens when users push each button?

• What happens when they submit the data?

At this point, you will probably identify many additional use cases. Collaboration between team members during this process will help ensure everyone understands exactly what you’re going to build.

The documentation and screen mock-ups help you understand how the finished product will look. Changes and compromises take place as software coders start to weigh in and begin designing the software and planning how they will build it. Sometimes, initial plans are thrown out due to the complexity of writing the code.

The coders’ opinions are important – they’re possibly the highest paid people in this process, and you don’t want to waste time. We have a saying: Don’t spend $50 on a $10 bottle of (insert your favorite drink here)! Building the software requires extensive review. It’s a negotiation between product owners (generally you), business analysts (the people figuring out the workflows, usability and use cases), the coders (who program the actual software), and the testers (who make sure it functions correctly). We’ll more talk about testing in Part 6.

While you’re creating the requirements, your coders are creating the design, and your testers are building their test plans. Often, these two groups work hand-in-hand using a methodology called Test Driven Development (TDD). TDD works best when you have a dedicated group of experienced software testers. Tests are built from the use cases and requirements, and the code is built to pass the tests. All of the work needs to be as comprehensive as possible, or the code will miss pieces of functionality.

Many coders are capable of abstract design and may contribute innovations and ideas during concept discussions. These discoveries may change the design. I have a couple of these people on my team, but during the past several years, coders coming into the job market have been trained to only build code exactly as they’re told. This can keep you from jumping ahead or skipping unnecessary steps along the way. I hope I’m wrong. I hope dozens of awesome people write me and scream at me that “coder/designer extreme rapid development programmers” are alive and thriving. Unfortunately, that’s not been my experience.

I’m not implying that today’s programmers aren’t smart – they know how to craft solid code that does exactly what you want. But a more narrow focus on coding makes the SDLC process all the more important. Programmers are very literal, and what you’ve documented in the requirements may NOT be the exact thing you’re thinking about in your head. Your needs must be clearly documented.

You’ve now hashed though and defined the requirements. The technical designs are done, you have a better idea of what the costs/time will be, and the test plans are created – It’s time to start coding. The programmers will go away for a while, and you won’t have any idea what they’re doing. If you’ve designed your requirements well, small pieces of software will arrive in your test bed every week or two. These will be pieces such as a login screen, the main menu, and other basic functions. These pieces won’t look good at first, and they may not be fully functional, but you can see everything as it takes shape.

There are several other foundational activities that I haven’t discussed about SDLC:

• Choosing your primary SLDC methodology (such as Agile)

• Selecting your technology platforms

• Setting up your software and build environments so you can actually deliver to customers.

You’ll have several of these technical questions to answer, but your software team needs to help you with these steps. I stress “team.” Don’t just hire contract programmers and expect them to be able to plan, build, deploy, test and support your software. If you’re going to build your own software, bite the bullet and hire people. You’ll need a mix of high, medium and entry level people in order to have a broad spectrum of experience to draw from. You need people that can get invested in your product’s success.

Next time, I’ll talk about testing, where we find out that nothing is ever perfect.

Todd Davis

Todd Davis, Vice President of IT – ReviewStat Services for UniMed Direct, is responsible for the continued development the industry-leading ReviewStat system. Leading a team of like-minded professionals, Todd works to review and improve ReviewStat’s full-featured and robust system to make it even more efficient and easy to use.