mobile web design and development best practice guide pdf
every software project needs a really good specification if its gonna succeed but it takes a lot of practice to able to write those specifications it is not easy. so today we are gonna look at a very simple approach that anybody can use to write solid specifications to get their project done right.
hey everybody, i'm dave hecker and today we are talking about how to write specifications for your outsource software project. let's first look at what the high level objective is of the specification. all you really want to do is communicate what you need to the developing team. it doesn't really matter how you do it, or the format
or what it looks like, or how you deliver it as long as you communicate it well, that's what we're going for. it's not easy to do but there is kind of a simple mentality that you can take that's going to help a lot. first you wanna keep in time that you should always put in as much detail
as possible, you can't have too much detail. repeating yourself a few times or putting into unnecessary detail waste a little tiny bit of space on usually a virtual document. forgetting something is a big expensive mess, so don't hold back try to get as much as you can. also imagine that the reader,
your developer, is coming with zero knowledge. explain everything no mater how rudimentary or obvious it seems get it down on paper. imagine they have nothing coming in that's going to help a lot, and they have to learn everything from scratch. use lots and lots and lots of words. don't go short.
don't try to be concise. really go for it. just keep talking or talking or whatever it is you do. so keeping those things in mind we're going to walk through an example and i'm going to show you how easy it can be. this is sort of a brainstorming exercise. people think that when you write a requirement to know
exactly what's going on in your application. you've got everything in your head and you're just writing it down but it doesn't really work like that. writing requirements is a brainstorming process in this example we're going to use a real example which is a site that tracks peoples weight loss. so, when this client comes to the service provider they
say i've got this great idea for the weight loss site and here are the requirements. and let's say one of the requirements says something like this. user's can see metrics about their workout. sounds good. the client is probably thinking there's going to be all kind of metrics, they can see how their workout are going, how
much weight they're losing, how much muscle their getting whatever it is. the developer, that doesn't mean anything, they're going to say what metrics are you talking about? i need more information. so already we can just add words. that's the main part of the exercise. it's just add stuff. let's see
if we can add just anything to that requirement. how about instead of user can see metrics about their work out, logged-in user you can see metrics about their work out. not very useful but we did add something into its true the idea of the exercise is just to add
stuff for brainstorming. so its ok that it is not really meaty. lets try it again. we can look at that and think well what kind of metrics are there? there could be lots of them. let's try one. logged-in user can see a progress chart showing their weight loss. now, this is getting good.
now we've got a specific metric in mind. we know the user is logged- in and we're starting to develop a real requirement. let's try to add one more thing. logged-in user can see the progress chart showing their weight loss period. the chart will show the users weight loss by day, week for a month.
now this is kind of getting interesting. now at least we're drilling down on one feature. it's okay to repeat yourself, like we say logged-in every time, it seems obvious right, but don't worry about that because we want the developer to be crystal, crystal clear. we don't mind repeating our words. okay, we're brainstorming that right now.
we're going to brainstorm in a totally different way we're gonna tell a user story. these are sometimes called use cases, sometimes called user stories, but it doesn't really matter. the idea is to get away from a requirement that says the user can do this and try something where it says, this user enters the site
and here's what they do and it's sort of a narrative. so let's try the same requirement as the user story. lets try like this. a user wanted to see their weight loss so they logged in to this site and they viewed a chart showing their progress. that's kind of the same requirement but its just said in a different way.
the reason it's so valuable is because now we're still brainstorming and we're going to think of a lot more stuff as we go. let's try it again, we'll add a little more brainstorming and we're adding stuff all the time. a user wanted to see their weight loss so they logged into the site, clicked on my progress and saw a chart showing their weight loss. this is even
better. now we came up with something new. the developer didn't knew that there was a area called my progress. so through this brainstorming process we started to go up navigation and it's getting more and more useful to the developer. let's try it again. a user wanted to see their weight loss so they
logged into the site, clicked on my progress and saw a chart showing their weight loss. their weight had gone up that week and because they were gaining weight the chart was displayed in red. now that might be something you just thought of while you were brainstorming that use case but it doesn't matter. if you
wanna capture it down, if its something you wanna do it write it down. you don't need to go from beginning to end and write down every single piece of the application in one go. it never works like that. consider it a brainstorming exercise and just jump around all over the place and when something comes to you just add it in.
just start typing, typing and typing and you'll drill down on each requirement just like we did on that one. after you add that one requirement go back to the use case and read that and then go back and forth and if you think of something else jump to another requirement. it doesn't matter. just alternate, keep moving.
so, to sum it up alternate between requirements and user stories. you want to be brainstorming. you want to keep adding stuff. you can never have too many words. repeating yourself is okay and imagine that the reader of the document was starting with zero knowledge. they're coming in totally cold.
so that's it for today. for more outsourcing advice, be sure to visit us a sourceseek.com and be sure to subscribe to our channel for weekly tips. we also want to hear from you . so please leave your comments and questions below. we are gonna answer every comment and question that comes in. we'll see you soon.
Tidak ada komentar:
Posting Komentar