Log in

No account? Create an account

Previous Entry | Next Entry



Did a first-pass addition of a feature, designed to requirements.

Today at a meeting I got jumped on because the feature didn't work like what they wanted. Unfortunately, it's partially a matter of the requirements not being clear. Essentially, what they want is something that will trigger the data collection and saving of a file some ten seconds before an event takes place.

Of course, that's impossible. What has to happen is that several seconds worth of data gets saved to a buffer that constantly refills and drops old data off the back end, then when the event happens, it saves tha buffer.

The problem is that the only data that is saved is not saved continually. It is saved in spurts, and the spurts are not necessarily contiguous: it could save one second out of every hour if that's the way it's configured.

One of the requirements states that this is the data that will be saved, but that's not what is actually wanted. What is wanted is that the data looks like this data, but it's actually different data. Data that's collected by a mechanism that doesn't actually exist yet.

It's further complicated by the separation of the data into groups. There is no mapping of the data into groups at the level where it is available, so I also have to synthesize the mapping. And I'm limited to the existing file format, and the fact that groups are computationally exclusive while data collection is not.

It's considerably back-to-the-drawing-board.


( 5 comments — Leave a comment )
Sep. 5th, 2006 10:08 pm (UTC)
This is why requirements should state what the desired outcome of a feature is.

I state things like so when I write requirements:

The system shall perform foo in order to enable bar information to be passed to the reporting system for use in the Very Important Stuff report.

I also do a requirements review with my dev guys, so they can ask questions like "what do you want to do with this buffer data?" and I can say "I want a continuous stream of logging" and then they can say, "Not gonna happen," or "Okay, then you need to reword this."
Sep. 5th, 2006 10:57 pm (UTC)
Yes, but you are *sane*.
Sep. 5th, 2006 11:02 pm (UTC)
It's an entirely new team, entirely new process for people that aren't used to it. One of the most telling comments was "There's a process for software?".
Sep. 5th, 2006 11:16 pm (UTC)
I'm so sorry.
Sep. 5th, 2006 11:00 pm (UTC)
Since we're just starting the whole SEPG process thing, a requirements review wasn't done, it was handed off to the PM with a deadline that if no comments were made, it would be accepted as-is.

This is of course a bad idea.

I've been pretty disappointed by the shortcutting crap that's been happening, and I've called it in the department meeting today. All of the developers are pretty much in agreement, and before we head into the new features, I wanna get some ground rules down, even if it means upsetting the PM.

This is gonna take me weeks to fix.

Thing is, we know the process. I mapped it out and have visio diagrams sent to everybody. We just shortcut it because we needed to appease the higher-ups with visible progress.

( 5 comments — Leave a comment )

Latest Month

April 2012


Page Summary

Powered by LiveJournal.com
Designed by Tiffany Chow