Requirements Analysis for web-based apps

[warpus]

Hi All

I know that we don't have many software/web engineers/devs here, but I thought I'd ask anyway.

My issue is that I'm the only developer in the office, with a non-developer supervisor who likes to take a hands on approach to project management - meaning that he'll stick his hands where they don't belong - specifically the requirements analysis part of the software development lifecycle.

Sure, a project manager can contribute to that part of the s.d.l. but you need a developer involved so that the right questions can be asked and the right information collected. If you're not a developer you're just not going to know what questions to ask. This is something I haven't been able to get across to our director, who trusts me.. but isn't very good at directing or telling people what's expected of them. What ends up happening is people do whatever they want, basically, sticking their fingers where they don't belong. My supervisor likes to think highly of himself and is decent at some of the stuff he does, but he doesn't really have a grasp of any aspect of software development at all. He says he's "coding" when he uses our content management system, for example.. Meanwhile he doesn't have any coding experience at all.

Anyway, recently I have been tasked with creating a task management system for myself and my supervisor so that we can better manage the stuff we do (we each do totally different stuff, but that's beside the point). So I built such a system which basically contains 2 types of objects: tasks and projects. Each project has a phase (which is one of the traditional 6 phases of the software development lifecycle: requirements analysis, design, implementation, testing, deployment, maintenance)

We just had a meeting about this and they love the task manager that I built. I explained to them that it's geared towards software development - since that's what I do and the system will be mainly for me.. but that it can be easily extended to work with any sort of type of task or project.

You wonder where I'm going with this.. During our discussions it became clear that our visions of who should be involved in what differ greatly. My supervisor thinks that he should be doing the requirements analysis part and passing it on to me, which is when I take over and do the rest. This just won't work. I told them that I need to be involved in that part of it... which they aren't against, it doesn't seem, but they don't understand how vital it is that a developer is present during that stage. edit: I should mention here that my supervisor thinks that he's a developer too, having no programming experience.

So I want to present to them some sort of a framework for requirements analysis collection that works for me and works for them. Obviously my supervisor needs to be a part of that part of the process for political reasons - making decisions on what I *should* be working on, telling a client "no", stuff like that. Political stuff. I should be there to say stuff like "that's impossible", "that wouldn't work with our current database structure", "you don't mean that, you actually mean this", "that is possible but would take a couple weeks of work to implement", asking for clarification on what the client really means and so forth. This division of duties makes perfect logical sense to me, but like I said my supervisor likes to stick his hands where they don't belong.. He doesn't think I should be at some of those initial meetings, because he's the "supervisor". And the director isn't going to divide our duties in that fashion that makes sense to me because he's not very good at directing.. and hey, he probably doesn't see it from my point of view anyway.

The goal: to find a requirements analysis framework that I can present to my supervisor and the director that 1. they can look at and go "Oh, we see, it really makes sense to divide up the duties this way. You should really be at all those meetings. Having your supervisor as a middleman will just lead to inefficiency and problems down the road.".. and 2. that actually improves the way we do business and makes us more efficient due to better requirements analysis collection, documentation, etc.

The thing is that nobody who does web development seems to do any sort of formal requirements analysis. The step is almost always skipped... sort of. You go to a couple meetings, take some notes, and that's it. I've looked up standard software requirement analysis frameworks, and most of the stuff is way over the top and would be overkill in a web development environment.. (by the way, when I say web development, I am talking about dynamic ajaxy database-driven web-based applications)

Things I've looked at are UML diagrams and use case diagrams.. which *could* work. But I'm just not sure if there's anything better out there? UML diagrams are probably a bit over the top, but maybe there is some simplified version that I could use? use case diagrams look a bit more like it, but again, I wonder if there's anything a bit more web-specific out there.

The problem is that if I don't find a good framework that we can use, my supervisor is just going to take this part of this process over and write up "project documents", as he calls them. It's basically a lot of business lingo with a lot of fluff that I don't care about, with a couple sentences in there describing what the finished product is supposed to do.. not written in any sort of developer-friendly way. Just, you know.. sentences.. of stuff. Not written by a person who has experience with software development. Usually this isn't a big problem because the projects are for the most part simple.. but it's annoying when I have to meet people to clarify stuff.. Usually I can just guess and figure out what crap means without getting a hold of anyone, but I don't really like to do that. It can lead to problems. It also annoys me.

If anyone is still reading, any ideas? Thanks

 

[warpus]

You know, if I could get my supervisor to draw up use case diagrams (with actors, actions, etc.) for the projects, I would probably be happy with that. I don't like having a middleman between me and the users of my software, but if I *have* to have one, then let him draw all the use case diagrams. Then if the user says "hey, that's not what I wanted", I get to blame my supervisor for messing up the use case diagram. It's not ideal by any stretch of the imagination, but it would reduce the annoyance level in my life.. and if there's one thing I hate it's being annoyed

 

[Zelig]

I would just tell them it's far more cost effective to sign up for something like Basecamp, Subernova, or one of the many other similar pieces of software rather than having me spend time reinventing the wheel.

 

[warpus]

I would just tell them it's far more cost effective to sign up for something like Basecamp, Subernova, or one of the many other similar pieces of software rather than having me spend time reinventing the wheel.

The task management web app I built is done. and is very simple. I looked at some existing software and it just did too much.

What I need now is just a proper and structured way to collect requirement analysis data... so that the supervisor can see that it *doesn't* mean just writing down some sentences and that it's actually an important step that should be structured in a meaningful way.

 

[Grisu]

when defining the requirements etc, we (the developers) usually draw up the use cases and present them to the client who then gives his input/changes.

once that's done, we draw up mock guis and sequence diagrams and present it again....

that said, requirements engineering/project management is the part I like least about software development....sadly, it's the direction I'll have to evolve to if I want to further my career..

 

[The_J]

You wonder where I'm going with this.. During our discussions it became clear that our visions of who should be involved in what differ greatly. My supervisor thinks that he should be doing the requirements analysis part and passing it on to me, which is when I take over and do the rest. This just won't work.

i see disaster coming.

Things I've looked at are UML diagrams and use case diagrams.. which *could* work. But I'm just not sure if there's anything better out there? UML diagrams are probably a bit over the top, but maybe there is some simplified version that I could use? use case diagrams look a bit more like it, but again, I wonder if there's anything a bit more web-specific out there.

You could try to make some relatively easy diagramm, which is already to complicated for him, and then convince him it's the most simple representation which is possible, so that he has to get you involved, because he's not capable of understanding the whole thing...but that's probably a bad idea, could result in the opposite.

But simpler than UML diagramms?
Flow diagramms, they are intuitive for most people, but i don't know if they are sufficient for whatever you exactly want to do.
...and add colours . All people love colours .


I'm somehow in the same situation. My supervisor can't program (and it's a woman, uaah), and i have no idea what her vision really is, and i'm if i knew it, it would not be the same like mine, and it will be complicated like hell. What a luck that i don't have any real pressure.

 

[innonimatu]

when defining the requirements etc, we (the developers) usually draw up the use cases and present them to the client who then gives his input/changes.

once that's done, we draw up mock guis and sequence diagrams and present it again....

that said, requirements engineering/project management is the part I like least about software development....sadly, it's the direction I'll have to evolve to if I want to further my career..

Yes, it's absolutely critical and too often totally neglected. Good software will be worthless if the intended users refuse to use it because it doesn't fit they way they want to do things. If the software is for internal use, make sure the users are involved with its design. Use cases and mockups are the standard first steps and worth the time.

Warpus, having your supervisor do those and talk to the intended users should drive home the point that correctly setting out the requirements is not simple. While you're at it, have him list the risks of project failure which he can see and avoidance/mitigation strategies. Though that might be overkill for a small project as this one seems to be. Oh, and don't waste time with UML diagrams. Seriously, it will be a waste of time.

 

[ParadigmShifter]

Use case diagrams are good. Get the client to talk to the supervisor and explain exactly what they want to do.

UML class diagrams are good for object oriented stuff but not that useful for procedural stuff, unless you want to specify a nice client side interface and show interactions between the various code modules.