BossTalks.com Tag: requirements

green on "Perfectionism is a disease"

green — Sat, 14 Apr 2007 21:07:17 +0000

I was glad to see this post from Paul Buchheit: "Perfect" is the enemy of "good enough" -- this is like sounding my own thoughts! Did Paul read my mind? Probably so. I would like to give just few quotes:

Forget about your lack of talent, skills, knowledge, time, resources, or whatever else you need to be "good enough". Start an inane blog, take bad photographs, upload boring videos to YouTube, write bad software, create useless products, play bad music, and make ugly art. Forget "good enough", and then simply indulge in the joy of creation.
...
But remember, although quality is nice, it's not the point.

This works. Really. Why? I am not sure I am qualified enough to give an answer about it, and it's hard to compose everything in a single post. But when you create something, even "okay" thing, you can pick an interest of "customers", who will be able to help making the best product. It's not about quality, perfect features or anything like that. It's about making something what customer wants.

Just read this post and be sure you understand it. Very nice said, because it's very simple.

(read more)

white on "Project scope: requirements"

white — Sun, 18 Mar 2007 15:30:26 +0000

Do you mean user requirements is a requirements gathered from a client? In this case you are correct, but you missed the original question then. :)

(read more)

melan on "Project scope: requirements"

melan — Sun, 18 Mar 2007 14:08:28 +0000

You are right I was too lazy to find out more types of constrains. Practically I'm not sure that it was obligatory. Main idea of my post related to User requirements. I wanted to point that the type of requirements is the base for any type of software development.

(read more)

white on "Project scope: requirements"

white — Sat, 17 Mar 2007 18:27:13 +0000

I don't know what projects are you working on, but it's strange that you have only so-called User requirements and Constraints, which you see only as a hardware requirements. Where should fit the requirements for OS, support, maintenance, software architecture, deployment procedure, etc?

(read more)

melan on "Project scope: requirements"

melan — Sat, 17 Mar 2007 15:50:24 +0000

The requirements are User requirements... Practically the requirements are the base for the whole development.
So just you need to ask your future customers: Hey guys! What do you want to see in the software when it will be ready?.. Also you need to make analysis of the other same products available on the market and note key features of the products. As the result you will have "user needs".
Another part of the work is to collect constrains. I tried to think out more then 2 of the constraints sources but I have only two: limitations related to physical world like light speed and limitations related to the computer world like speed of CPUs available now

(read more)

white on "Project scope: requirements"

white — Thu, 15 Mar 2007 07:58:47 +0000

You are really wrong in your point. There is nothing abstract in either functional or non-function requirements. These are definitions which are used to be the part of common terminology for years. The functional requirements are requirements which are absolutely required by the project and specify what the project or product should do. The non-functional requirements demonstrate the properties that the project or product should have to do what it must do (in other words to follow the functional part).

I know sometimes people tend to say that it doesn't matter how do you call the thing unless it does its job, but would you imagine if everyone would name the dog in a different way? It leads to chaos and absolute no-way for your career growth. But don't miss my point. There are different statements for what are those requirements, and all of them are coming to a single point. Besides, the standards are really important in the business.

(read more)

krivitsky on "Project scope: requirements"

krivitsky — Thu, 15 Mar 2007 04:47:57 +0000

my experience shows that it doesn't really matter how you call the pieces of requirements as long as you're staying focused on the end users' needs.
if you have your users by your side while moving iteratively and incrementally - eventually you'll have all the *needed* pieces of requirement there.

an excellent activator for us is user stories.
they keep us thinking on the users needs instead of more abstract constraints vs. functional vs. non-functional requirements.

i am not saying one should not care about non-functional requirements or constraints...

(read more)

white on "Project scope: requirements"

white — Wed, 14 Mar 2007 22:12:40 +0000

Speaking about typical project scope of a kind-of-waterfall-model project management strategy, what kind of requirements do you usually gather? Functional and Non-functional requirements sound like a must-have and pretty straight forwarded. But what about General (or global) requirements and Constraints?

I got pretty messed up with some people, trying to distinguish General requirements (which are also called as Constraining requirements) and Constrains. From my experience, I never saw them doing different job.

The General requirements are the ones that describe the highest level of requirements for specific project or system.

The Constrains are named requirements that must met at the top level of every entire project or system.

I do not feel either difference in specification or in idea. Both of them are required to achieve the same goal -- to describe the root and very core requirements of the projects.

Your thoughts and feedback would be highly appreciated.

(read more)

abresko on "How ISVs come with a requirements?"

abresko — Wed, 14 Mar 2007 13:39:20 +0000

I just have my own vision with a product. Once accomplished, I'll wipe my ass selling it, and then I hope my client will help me improving it (I mean - by using his feedback). I don't know for sure if people will want to buy my product, but I sincerely hope so ;-) I am risking, yes, but these risks I have to accept.

(read more)

johnw on "Review of two books which I call " Risks and Agile""

johnw — Tue, 13 Mar 2007 06:37:08 +0000

Thanks, I am getting "Practices of an Agile Developer" for myself ;-)

(read more)

green on "How ISVs come with a requirements?"

green — Tue, 06 Mar 2007 22:25:19 +0000

In my understanding, from the very beginning you have to start building system which is going to solve problems. People buy solution, but not software. Really hard, although, to answer this question in full. It's not clear anything about requirements which they are getting, or the way people are doing software development in this company at all. And of course, there is no unique and perfect answer which will name the software to be sold better. :-)

(read more)

white on "How ISVs come with a requirements?"

white — Tue, 06 Mar 2007 22:06:11 +0000

Nice topic raised on another forum, I feel it's pretty connected to BossTalks.

"I do system software development. I do not have any experience at a small company where we have to decide what we think people will spend on money and then build that software.

I get my requirements from business analysts or from government specialists. I basically get lists of "shall" statements that we have to analyze and turn into software.

System X shall do this

and so on.

However, if you are at a small company you have to come up with an idea and then incrementally improve it. How do you figure out what people want to buy?" (originally posted by Contractor)

(read more)

green on "Review of two books which I call " Risks and Agile""

green — Sat, 03 Mar 2007 21:54:08 +0000

Thinking recently about risks management for software projects, I came across few books, which I read, and truth to be told - enjoyed them:
"Practices of an Agile Developer: Working in the Real World" by Venkat Subramaniam and Andy Hunt
and
"Skills for Managing Rapidly Changing IT Projects" by Fabrizio Fioravanti

Although they are not answering straight to the question "what to do with all these risks", they are very helpful in organizing your own thoughts on what can help. Frankly speaking, I really strongly believe that there are a big amount of cases when agile methodologies can be helpful with some risks management. The biggest advantage at the moment I see in numerous and highly-frequent iterative milestones and builds. Unit tests are very helpful as well. And last but not least is a simple and small design. With all the cases I had before, I found these to be the biggest helpers in all situations. I also very much believe that proper requirements gathering is the second key to success. We want customer to be satisfied, so this need to be done to satisfy him, not you. However, that goes without saying that in such case we will get into permanently changing requirements but applying proper iterative development can give us the way out. Remember I mentioned small and simple design? There is just no universal architecture, there is no silver bullet in building software. So let's stay simple and not to create headaches for ourself before we really need it.
One of the biggest problem for many managers and customers is the lack of architectural and software development skills. They do not need to be _professional_ and _best of the best_ architects and/or developers, but they really need to know how to do things on a very low level. When noticing this, you have to get everything in your hands and control it. There are bunch of stupid cases (actually mentioned in the books above) when customer by requesting some idiotic things can screw up the success of the project. Keep in mind, that you, as a project manager/team lead need to be right here next to him to prevent this to happen, to protect him even from his own utopia. Not always possible, but you can and have to influence many things by operating easy facts. This will definately help.

Overall, it's an enjoyable reading. I liked it. Would recommend!

(read more)

green on "My review of "Mastering the Requirements Process" book"

green — Sat, 03 Mar 2007 21:11:40 +0000

I decided to share here my review of "Mastering the Requirements Process" book by Suzanne Robertson and James Robertson.
The book is not about Java development (which I am primary into), but about software development process - requirements gathering. The first thing I noticed in it is that it contains pretty much of quotes from other books. From Agile-about books. And I really liked the way how authors pointed out pros and cons. That's awesome - there is no silver bullet, and agile processes should not be used blindly like it happens too often nowadays!
I also liked that this book has some example of specifications template, which can be followed when preparing your own requirements. Also, every section of the process is clearly stated and given with different examples, and detailed explanation. May be even too detailed, but this goes next :-)
What I don't like is that there are few diagrams which looks funny and easy, but not strictly clear and official. Sometimes I wish things to be more standard. I.e. they showed formal SDLC process in too funny way. Don't like that. It's not that hard, and diagrams of SDLC are sooo well known, so doing it "funny" isn't nice. And I didn't like that it's too big. I mean the whole book. Well, you can minimize given material at least 1.5 times. But may be it's only my preference?

As for the overall picture - one thumb up, and half thumb up. So, I can say - it is 4 of 5 stars. I think this is the best book covering requirements gathering topic I ever read till date. I would recommend this book.

(read more)