2

Who are the stakeholder of the software requirement specification? My UI designer keeps pressing us for the program flow.

I thought the designer should be giving us what should be included on each page. It seems like like there is an overlap of roles here. Please enlighten me.

Improve this question
  • 2
    Hello Bryan, welcome to PMSE! In the second sentence, who's 'us'? The development team? Notice that the idea of all SE sites is to make questions useful to as much people as possible, so you can consider rewrite it in a way the community could take advantage of the answers. Thanks! – Tiago Cardoso♦ Aug 29 '13 at 4:26
  • Definition of an SRS: en.wikipedia.org/wiki/Software_requirements_specification. – Todd A. Jacobs♦ Aug 29 '13 at 4:39
  • Do you mean the actual stakeholders, or the owner or producer of the document? – Todd A. Jacobs♦ Aug 29 '13 at 4:42
2

The short answer is that there may well be overlap in interests, which is manifesting itself into an overlap of roles. More likely it is a miscommunication about the order of delivery of products.

Now for the longer answer.

There are a few different buckets of stakeholders. Depending on who you talk to the number and labels for the buckets varies, but generally speaking you have:

  • Customers/End Users. This includes whoever will take a product and use them operationally.
  • Producers. This includes whoever actually makes a product (software, document, etc) for delivery to the customer.
  • Interested Third Parties. This is a catch-all and includes those that support and oppose the project for one reason or another but don't fit into the other buckets.

A key thing to remember is that particular people/organizations/entities can shift between buckets as a project progresses, and there will almost always be more than one in a given bucket at a given time... and depending on the context one person could be in more than one bucket at the same time.

In your case, the UI designer sees himself as being in the "Customer" bucket, expecting to receive a program flow prior to developing the UI. You see him as being a "Producer", delivering you requirements, presumably so that you can work out the program flow.

I think what you need to do is sit down and work through your product flow. This is similar to a work flow, but documents which products are needed to develop other products. To do this:

  1. Develop a product break-down structure (PBS) to define all the pieces that go into the product(s) that your project will generate.
  2. Determine which components of the PBS are necessary to produce other components.
  3. Document these in a flow diagram to help visualize the relationships.

Once you have the product flow together it should be relatively straight-forward to figure out who is a customer and who is a producer for each deliverable. This will help avoid misunderstandings.

Improve this answer
  • 1
    I liked the buckets of stakeholders presented. It makes things quite simple. – Tiago Cardoso♦ Aug 29 '13 at 16:28
0

What should appear on the page is not only a designer's task. Other roles will also have to step-in. Depending on the type of team-members one has in the team, this is supported by Business Analysts, few Developers, of course Designers and Client Representatives who have a say in the page design.

There could be a requirement to follow certain design approaches or layouts or color-combination, et al. which the designer cannot decipher on her own. If your designer is pushing for program flow, she seems right to me.

Designing pages without being able to see their interconnection, if any or the big-picture and the users' context may lead to a bad design. Given a proper program flow, your designers would be in a better position to give you a usable design which may need lesser changes later on.

Improve this answer
0

Stakeholders are those people who directly or indirectly involved in the project, who positively or negatively affected by the performance and completion of the project. The first thing you should do is to make a PBS through which you can easily identify the possible outcomes required for a project. You have to break the complete project in the smallest components so that you can get as much details as possible. After determining all those things go for designing and coding part.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.